info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ForestLib / SpaceBeatz / Thumb, code for game dev now open source (plus The Lady source code for sale)
358 views
Skip to first unread message
Roger Levy
Jul 8, 2014, 7:17:08 PM7/8/14
to
Published here is part of my personal SwiftForth codebase.
The base of it all is ForestLib. As in that old idiom about trees. It does use a custom dialect, but not very far from ANS94. My OOF is called Prototype. Its focus is on being pretty much a layer of convenience on top of ordinary Forth programming. It does not do any fancy polymorphism out-of-the-box. There is a way provided to implement "messages", called vtables. In fact Prototype focuses on convenience so it's not very restricting and some might call it incomplete - I call it useful. It is not, however, stable, and will be tweaked and refined as time goes on.
I've spent a lot of time building up a good workflow - hopefully this will help foster some advancement. Foremost from a workflow perspective are my use of a new word FLOAD that facilitates modular program design, and session files. Check the readme file.
I'm attaching a "sample game", though it's actually not really a game yet. It's a musical Space Invaders-inspired game. It's currently on the backburner but in time I'll get back to it. I've been busy learning Unity. Maybe somebody will figure it out and make something cool out of it before I get a chance to get back to it. (I can dream :P)
To load/compile SpaceBeatz, you will also need Thumb, a usable 2D game engine which came pretty much directly out of The Lady.
Here are the repos if you want to watch development or even contribute. All this stuff is open source. The game might not be open source forever, though.
https://bitbucket.org/rogerlevy/forestlib
https://bitbucket.org/rogerlevy/spacebeatz
https://bitbucket.org/rogerlevy/thumbengine
Requirements:
SwiftForth 3.5.3+
Windows 7 and up
OpenGL/DirectX compliant video driver
512MB RAM
Directions:
1. Download this zip file: https://www.dropbox.com/s/0v4dqzs8nfc1rqz/GAMEDEV_140603.zip
2. Unzip that zip file to a folder, like your projects folder.
3. INCLUDE spacebeatz\spacebeatz-forth\session.f and a test should run.
4. If you use Komodo Edit, open the included spacebeatz-forth.komodoproject and press F5. (I don't know if this will work - let's see how it goes.)
I apologize for the lack of comprehensive docs. This stuff is already evolving and I really need a paying project to be able to spend more time on it. Your best bet is to crack some files open and just start reading and loading stuff and trying it out. After reading the readme file of course. If there old misleading info anywhere, please don't come after me. Rigor isn't my most dominant trait.
Happy to answer questions and discuss. I'll do my best.
Follow me on Twitter to keep up with my gamedev stuff. @kidfingers
P.S.:
Want a complete game to tinker with?
I am offering The Lady's source code for sale. The Lady is a 2D hidef 5-stage surreal action/art game that was commercially released back in May. It has not sold crazily well (we've made $600 so far), so, I'm gonna try to help make up for that because I did spend about 3 months on it. Price is $30, send me a Paypal and I will send you a link. I will also give you priority support for a couple months.
The base of it all is ForestLib. As in that old idiom about trees. It does use a custom dialect, but not very far from ANS94. My OOF is called Prototype. Its focus is on being pretty much a layer of convenience on top of ordinary Forth programming. It does not do any fancy polymorphism out-of-the-box. There is a way provided to implement "messages", called vtables. In fact Prototype focuses on convenience so it's not very restricting and some might call it incomplete - I call it useful. It is not, however, stable, and will be tweaked and refined as time goes on.
I've spent a lot of time building up a good workflow - hopefully this will help foster some advancement. Foremost from a workflow perspective are my use of a new word FLOAD that facilitates modular program design, and session files. Check the readme file.
I'm attaching a "sample game", though it's actually not really a game yet. It's a musical Space Invaders-inspired game. It's currently on the backburner but in time I'll get back to it. I've been busy learning Unity. Maybe somebody will figure it out and make something cool out of it before I get a chance to get back to it. (I can dream :P)
To load/compile SpaceBeatz, you will also need Thumb, a usable 2D game engine which came pretty much directly out of The Lady.
Here are the repos if you want to watch development or even contribute. All this stuff is open source. The game might not be open source forever, though.
https://bitbucket.org/rogerlevy/forestlib
https://bitbucket.org/rogerlevy/spacebeatz
https://bitbucket.org/rogerlevy/thumbengine
Requirements:
SwiftForth 3.5.3+
Windows 7 and up
OpenGL/DirectX compliant video driver
512MB RAM
Directions:
1. Download this zip file: https://www.dropbox.com/s/0v4dqzs8nfc1rqz/GAMEDEV_140603.zip
2. Unzip that zip file to a folder, like your projects folder.
3. INCLUDE spacebeatz\spacebeatz-forth\session.f and a test should run.
4. If you use Komodo Edit, open the included spacebeatz-forth.komodoproject and press F5. (I don't know if this will work - let's see how it goes.)
I apologize for the lack of comprehensive docs. This stuff is already evolving and I really need a paying project to be able to spend more time on it. Your best bet is to crack some files open and just start reading and loading stuff and trying it out. After reading the readme file of course. If there old misleading info anywhere, please don't come after me. Rigor isn't my most dominant trait.
Happy to answer questions and discuss. I'll do my best.
Follow me on Twitter to keep up with my gamedev stuff. @kidfingers
P.S.:
Want a complete game to tinker with?
I am offering The Lady's source code for sale. The Lady is a 2D hidef 5-stage surreal action/art game that was commercially released back in May. It has not sold crazily well (we've made $600 so far), so, I'm gonna try to help make up for that because I did spend about 3 months on it. Price is $30, send me a Paypal and I will send you a link. I will also give you priority support for a couple months.
Roger Levy
Jul 8, 2014, 7:21:32 PM7/8/14
to
Here's The Lady's IndieDB page for those who haven't heard of it: http://www.indiedb.com/games/the-lady
Source code / support is for sale $30. Send by Paypal.
Source code / support is for sale $30. Send by Paypal.
Jason Damisch
Jul 9, 2014, 12:28:55 PM7/9/14
to
Thank you for your effort, and for posting here about your projects.
Jason
Jason
Pablo Hugo Reda
Jul 9, 2014, 1:06:05 PM7/9/14
to
I happy to see more open source lib in forth
Good luck with you game too Roger !!
Good luck with you game too Roger !!
Roger Levy
Jul 10, 2014, 9:01:11 PM7/10/14
to
So... I guess the interest in games is low here, which isn't surprising, and it's not the weekend, but, has anybody tried it out yet?
Jason Damisch
Jul 10, 2014, 10:08:36 PM7/10/14
to
On Thursday, July 10, 2014 6:01:11 PM UTC-7, Roger Levy wrote:
> So... I guess the interest in games is low here, which isn't surprising, and it's not the weekend, but, has anybody tried it out yet?
I promise that when I get a Win7 machine that I'll try your games then.
> So... I guess the interest in games is low here, which isn't surprising, and it's not the weekend, but, has anybody tried it out yet?
Jason
Jason Damisch
Jul 10, 2014, 10:19:17 PM7/10/14
to
On Tuesday, July 8, 2014 4:17:08 PM UTC-7, Roger Levy wrote:
> has not sold crazily well (we've made $600 so far),
Sounds like messed up economics. This reminds me of the economic environment of Second Life. I doubt if anybody has made enough money in there working with Prims to even buy a cup of coffee in the morning.
> has not sold crazily well (we've made $600 so far),
If that is what you can bank with a video-game, I'd have to reconsider my options. I mean, maybe it's possible to make some money writing games these days, but I'm not sure how. I remember back in the good old days when half of the planet wasn't irradiated, when a couple of hippies working in their garage could make a game for an 8 bit computer, put it onto cassette tape, sell it, and then make enough money to buy a car and then go on a road trip with the rest of the cash.
If I was going to make a game, I'd need to look at what indie video-games are selling well, which have been written by a few guys rather than by a large team of people, and see if I could figure out what makes that success tick.
Maybe you can do it, but you would need to find the right angle. What about a straight 2D action arcade game? Something like Rastan? What about something that networks over the net? What about something that people can contribute to and write levels for? I do have some ideas, but I'm not sure if the amount of time which would needed to implement them would justify the effort.
Or you could get really lucky and come up with a brand new original idea that ends up selling a million copies, like Angry Birds.
My $0.2 worth
Jason
Roger Levy
Jul 10, 2014, 11:43:24 PM7/10/14
to
> Sounds like messed up economics. This reminds me of the economic environment of Second Life. I doubt if anybody has made enough money in there working with Prims to even buy a cup of coffee in the morning.
The first hurdle is the concept itself. It's really uncomfortable to play, surreal, and just plain creepy. This was intentional and what drew me to the project in the first place. But marketing a thing like this has to be done right. It has to frame it right, get you into it. The marketing had to make it more than what it was.
The game was completed more-or-less on schedule, however, it was only a few notches above the bare minimum of what we laid out in the design document and this was due to just unforeseen difficulties - not all of which even had to do with coding itself - sometimes it was just burnout and personal issues. If I had it my way, we should have put another month into it. Mike didn't want to risk it. I was at the limit of the extra time I put in for basically free, and he didn't want to spend any more, which I think might have made all the difference. He got antsy. I don't blame him.
It's also a really short game - an hour for an average player. And not much replay value. It's priced accordingly: $3 a pop. Given that, we actually haven't done too bad. We actually made a little money from crowdfunding before the game was released, and those people got copies. Many games don't sell at all or never make enough to get a payout from their distributor. Mike probably thought thousands of people would buy it just because it looks different.
Yet another thing holding sales back is the limited platform spread. Just Win7 + Win8. It really should be Mac and Linux at least. Vista too, maybe. I can't port it myself because of lack of funds and knowledge and time. I'm trying to get some help to do it. I'd pay them.
> If that is what you can bank with a video-game, I'd have to reconsider my options. I mean, maybe it's possible to make some money writing games these days, but I'm not sure how. I remember back in the good old days when half of the planet wasn't irradiated, when a couple of hippies working in their garage could make a game for an 8 bit computer, put it onto cassette tape, sell it, and then make enough money to buy a car and then go on a road trip with the rest of the cash.
In the end I wish the game could have just been made a little better before release. Mike cut the ending down to a slap in the player's face - it's comedic, if you get the joke. But not very satisfying.
> If I was going to make a game, I'd need to look at what indie video-games are selling well, which have been written by a few guys rather than by a large team of people, and see if I could figure out what makes that success tick.
> Maybe you can do it, but you would need to find the right angle. What about a straight 2D action arcade game? Something like Rastan? What about something that networks over the net? What about something that people can contribute to and write levels for? I do have some ideas, but I'm not sure if the amount of time which would needed to implement them would justify the effort.
I would definitely be up for doing something more marketable in Forth. Believe me with a good idea and solid execution (I've got the second part covered) it is well worth it. If it's an idea that could thrive on PC's it could work.
> Or you could get really lucky and come up with a brand new original idea that ends up selling a million copies, like Angry Birds.
Forth is so great for iteration and experimentation. It can be so much more fluid than anything else available. It has annoyances and problems like anything else but they are just different. If those could be solved then it'd be a hell of a secret weapon. I love working in it.
Jason Damisch
Jul 11, 2014, 11:16:52 AM7/11/14
to
I'd like to write about my game some.
Skampy, a 2D Pacman type game, or gobble game, was never released to the public. I had a few private showings, I doubt that any more than 10 people have actually played it. It was made available as a download at some point, but is no longer downloadable.
It only works on Atari ST. It works well under emulation, although when I tried it in my emulator, the sound was off. The game was written for a joystick and playing with a keyboard may not be completely satisfying. It require some very tight corner turning.
What did I learn from the experience? I take it that those who write the game should not also the be those that play test it. For one thing, you already know how to beat it because you wrote it. Second, as a programmer, its probably impossible to have an unbiased perspective of the difficulty of the game. Granted, everybody has their own abilities as far as playing arcade games go. My game had a few very easy levels, and then some levels that were too difficult, and which should have been redone.
As far as potentially making money is concerned, I finished it in 1999, well after the life of the ST was over with. If I had finished it in 1990, I could probably have sold it to a magazine for $500 if I had polished it up a bit more, and improved the level design to moderate the difficulty level.
As far as other amateur efforts in Atari ST games, I've seen stuff that was released to the public, but which was much worse than Skampy. How does it feel to create something of almost professional quality ( for 1990 ). Hmmm...
Why did I write it? I had wanted to complete a videogame from the time I was a child. I tried in Atari Basic on the 800XL, and old interpreted BASIC was just too slow to get the job down. I had finished a very buggy game called Recovery which involved shooting UFOs and recovering canisters of radioactive waste scattered throughout the screen, taking them to a central location on the screen, a waste disposal unit, and dropping them off there. It was so buggy that you could shoot a bullet through the borders of the screen at a few spots, and the bullet would then travel through program code. Silly.
In Skampy, I wrote a fast, playable game with sound, cute graphics, responsive joystick control, scoreboard, levels, and there is even an cartoon if you can get to the end of the games 10 levels. I'm convinced to this day that Forth is 100% better in every way than old interpreted BASIC.
BASIC BLAH = . -1
I wanted to prove to myself that I could write a game, and I did.
Jason
Skampy, a 2D Pacman type game, or gobble game, was never released to the public. I had a few private showings, I doubt that any more than 10 people have actually played it. It was made available as a download at some point, but is no longer downloadable.
It only works on Atari ST. It works well under emulation, although when I tried it in my emulator, the sound was off. The game was written for a joystick and playing with a keyboard may not be completely satisfying. It require some very tight corner turning.
What did I learn from the experience? I take it that those who write the game should not also the be those that play test it. For one thing, you already know how to beat it because you wrote it. Second, as a programmer, its probably impossible to have an unbiased perspective of the difficulty of the game. Granted, everybody has their own abilities as far as playing arcade games go. My game had a few very easy levels, and then some levels that were too difficult, and which should have been redone.
As far as potentially making money is concerned, I finished it in 1999, well after the life of the ST was over with. If I had finished it in 1990, I could probably have sold it to a magazine for $500 if I had polished it up a bit more, and improved the level design to moderate the difficulty level.
As far as other amateur efforts in Atari ST games, I've seen stuff that was released to the public, but which was much worse than Skampy. How does it feel to create something of almost professional quality ( for 1990 ). Hmmm...
Why did I write it? I had wanted to complete a videogame from the time I was a child. I tried in Atari Basic on the 800XL, and old interpreted BASIC was just too slow to get the job down. I had finished a very buggy game called Recovery which involved shooting UFOs and recovering canisters of radioactive waste scattered throughout the screen, taking them to a central location on the screen, a waste disposal unit, and dropping them off there. It was so buggy that you could shoot a bullet through the borders of the screen at a few spots, and the bullet would then travel through program code. Silly.
In Skampy, I wrote a fast, playable game with sound, cute graphics, responsive joystick control, scoreboard, levels, and there is even an cartoon if you can get to the end of the games 10 levels. I'm convinced to this day that Forth is 100% better in every way than old interpreted BASIC.
BASIC BLAH = . -1
I wanted to prove to myself that I could write a game, and I did.
Jason
Roger Levy
Jul 17, 2014, 11:03:52 AM7/17/14
to
GameBlocks[2], the 2nd iteration of my personal collection of game-specific components, is usable now - just pushed the latest (https://bitbucket.org/rogerlevy/forestlib)
In my versioning system, version increments signify backwards-incompatible changes.
Notable are these changes from [1]:
* Adoption of "getters" and "setters" for certain data structures where they add clarity. High-level code shouldn't be using 2@ etc. For example now we say POS X or POS XY instead of POS >X @ or POS 2@, or worse, POS @,
* The notation of explicitly-addressing fields ( addr -- addr+? ) has changed from >FIELD to .FIELD for better readability. > has a tendency to blend into surrounding characters and we needed something more distinct. Besides, now > is free to use for more abstract "to-something" type words, and so can be used to encapsulate things.
* -> is deprecated (and only included for temporary backward compatibility with some files) since it encouraged "reaching into" objects' internal-ish words.
* %rectangle is superceded by %box
* A slew of packed-flags words have been added.
* %bitmaps are now %images
* In the Allegro component, a set of words have been added that wrap graphics functions with long parameter lists more conveniently and efficiently. As a result configuring floating point to use a software stack is no longer required.
* Following this the settings for floating point are now hardwired to use a hardware stack and other settings, and the fpmath config window was removed.
* A couple fixes and improvements in vtable_2.f
I am currently using GameBlocks[2] to develop Studio UI.
In my versioning system, version increments signify backwards-incompatible changes.
Notable are these changes from [1]:
* Adoption of "getters" and "setters" for certain data structures where they add clarity. High-level code shouldn't be using 2@ etc. For example now we say POS X or POS XY instead of POS >X @ or POS 2@, or worse, POS @,
* The notation of explicitly-addressing fields ( addr -- addr+? ) has changed from >FIELD to .FIELD for better readability. > has a tendency to blend into surrounding characters and we needed something more distinct. Besides, now > is free to use for more abstract "to-something" type words, and so can be used to encapsulate things.
* -> is deprecated (and only included for temporary backward compatibility with some files) since it encouraged "reaching into" objects' internal-ish words.
* %rectangle is superceded by %box
* A slew of packed-flags words have been added.
* %bitmaps are now %images
* In the Allegro component, a set of words have been added that wrap graphics functions with long parameter lists more conveniently and efficiently. As a result configuring floating point to use a software stack is no longer required.
* Following this the settings for floating point are now hardwired to use a hardware stack and other settings, and the fpmath config window was removed.
* A couple fixes and improvements in vtable_2.f
I am currently using GameBlocks[2] to develop Studio UI.
Jason Damisch
Jul 17, 2014, 12:48:53 PM7/17/14
to
On Thursday, July 17, 2014 8:03:52 AM UTC-7, Roger Levy wrote:
> * Adoption of "getters" and "setters" for certain data structures
> where they add clarity. High-level code shouldn't be using 2@ etc.
> For example now we say POS X or POS XY instead of POS >X @ or POS
> 2@, or worse, POS @,
I appreciate that you are doing something. I want to clarify that I am not critical. But, I happen to like POS @ and such. I happen to not like going ahead in the input stream for anything if I can help it. I've even thought about writing Forth in a way which requires one to put a name of a word to be defined on the stack, and then calling the word creation word which takes the string off of the stack instead of going ahead in the input stream to get it. I ought to actually read your system though to be sure exactly what you are doing.
> * Adoption of "getters" and "setters" for certain data structures
> where they add clarity. High-level code shouldn't be using 2@ etc.
> For example now we say POS X or POS XY instead of POS >X @ or POS
> 2@, or worse, POS @,
> * The notation of explicitly-addressing fields ( addr -- addr+? )
> has changed from >FIELD to .FIELD for better readability.
> > has a tendency to blend into surrounding characters and we needed
> something more distinct. Besides, now > is free to use for more
> abstract "to-something" type words, and so can be used to encapsulate
> things.
I'm not sure that .FIELD is any better than >FIELD because I usually think of dot as meaning being printed on the screen. Granted, I am sometimes stumped by the fact that there are just so many special symbols on my keyboard to express different things with, and these special symbols tend to get reused, potentially making my code confusing for others. Sometimes I wish that I could program using WingDings, but then again, that might be even more confusing, and create other problems as well.
> As a result configuring floating point to use a software
> stack is no longer required.
Jason
Roger Levy
Jul 17, 2014, 1:23:43 PM7/17/14
to
> I appreciate that you are doing something. I want to clarify that I am not critical. But, I happen to like POS @ and such. I happen to not like going ahead in the input stream for anything if I can help it. I've even thought about writing Forth in a way which requires one to put a name of a word to be defined on the stack, and then calling the word creation word which takes the string off of the stack instead of going ahead in the input stream to get it. I ought to actually read your system though to be sure exactly what you are doing.
To get things straight, my OOF doesn't do any binding out of the box. The definition for X is very dumb:
macro: x @ ;
"POS @" is a theoretical sin. You wouldn't want to do that because it's unclear which coordinate you're fetching, and could be easily misconstrued for a typo.
If I ever did it and caught myself I'd change it right away to at least POS >X @ in the old way of doing things. Honestly, the @'s and !'s are fine for low level code but I now consider them noise in higher level code, to be minimized.
Go check out the repo and peruse the source. It's not an insanely huge amount, just modestly huge. :)
> I'm not sure that .FIELD is any better than >FIELD because I usually think of dot as meaning being printed on the screen. Granted, I am sometimes stumped by the fact that there are just so many special symbols on my keyboard to express different things with, and these special symbols tend to get reused, potentially making my code confusing for others. Sometimes I wish that I could program using WingDings, but then again, that might be even more confusing, and create other problems as well.
This stuff is primarily internal. 2nd or 3rd level wordsets should use the getter/setter convention, or encapsulate. I think that struct fields don't always need to be exposed to the entire application.
> My current thinking is that floating point is not necessary for 2D games, but is required for talking to libraries which generate 3D graphics.
I use fixed-point for all actor physics.
Studio UI is currently based on integers since it's not meant to have any physics.
I have a handful of words that allow you to avoid having to type in decimal points. ?P converts all integers 65536 and up
Roger Levy
Jul 17, 2014, 1:26:34 PM7/17/14
to
Crap, a part of that post was lost.
here's the real definition of X
macro: x .x @ ;
and here's the setter
macro: x! .x ! ;
to finish the sentence in the middle about .NAME: it overlaps part of the meaning of field-dot in that it implies that it expects something to be passed to it.
to finish my last sentence, ?P converts numbers 65536 and up or -65536 and below to fixed point.
here's the real definition of X
macro: x .x @ ;
and here's the setter
macro: x! .x ! ;
to finish the sentence in the middle about .NAME: it overlaps part of the meaning of field-dot in that it implies that it expects something to be passed to it.
to finish my last sentence, ?P converts numbers 65536 and up or -65536 and below to fixed point.
Coos Haak
Jul 17, 2014, 3:43:15 PM7/17/14
to
Op Thu, 17 Jul 2014 10:23:43 -0700 (PDT) schreef Roger Levy:
> I thought about ".". I realized that the dot was most likely
> originally meant by Moore to be a punctuation mark, a period
> at the end of a sentence, to display the result of a calculation.
>The things we're doing are generally more sophisticated than that.
>The convention to use it to mean "print" is awkward and old; I've
> tossed it. I only use a few "dot means print" words. ".", ".s",
> and my own ".name" for actors. But I could easily change .name to
> name? or just leave it - the dot overlaps
What a strange remark. I've looked in a lot of Forth's and words that
contain a dot are mostly words that print.
The word . is definitely no delimiter, it prints a number since the
beginnings of Forth. So are .r d. .r u.
Perhaps ." and .( are minor exceptions, they print strings.
In combination like .field .address .postcode I can agree to the use in
structures.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
> I thought about ".". I realized that the dot was most likely
> originally meant by Moore to be a punctuation mark, a period
> at the end of a sentence, to display the result of a calculation.
>The things we're doing are generally more sophisticated than that.
>The convention to use it to mean "print" is awkward and old; I've
> tossed it. I only use a few "dot means print" words. ".", ".s",
> and my own ".name" for actors. But I could easily change .name to
> name? or just leave it - the dot overlaps
contain a dot are mostly words that print.
The word . is definitely no delimiter, it prints a number since the
beginnings of Forth. So are .r d. .r u.
Perhaps ." and .( are minor exceptions, they print strings.
In combination like .field .address .postcode I can agree to the use in
structures.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Roger Levy
Jul 17, 2014, 3:52:11 PM7/17/14
to
> What a strange remark. I've looked in a lot of Forth's and words that
> contain a dot are mostly words that print.
> The word . is definitely no delimiter, it prints a number since the
> beginnings of Forth. So are .r d. .r u.
> Perhaps ." and .( are minor exceptions, they print strings.
> In combination like .field .address .postcode I can agree to the use in
> structures.
The way . kind of took off as a convenient is another big reason why it's so weird. Something simple became something complex. Keep in mind it was designed originally to be optimal on a text-based interface, where you'd be calling it a LOT. I rarely call it, more often calling ? or referring to the stack display. There's no reason to continue adhering to that convention in a graphical environment, which is what I'm moving towards. Not that I plan on redefining it or anything. I just decided to let go of that barrier to using the dot notation, which I've found to be much nicer than the way it was before. So I've solved a problem and threw away a non-problem.
> contain a dot are mostly words that print.
> The word . is definitely no delimiter, it prints a number since the
> beginnings of Forth. So are .r d. .r u.
> Perhaps ." and .( are minor exceptions, they print strings.
> In combination like .field .address .postcode I can agree to the use in
> structures.
Roger Levy
Jul 17, 2014, 4:12:38 PM7/17/14
to
> The word . is definitely no delimiter, it prints a number since the
> beginnings of Forth. So are .r d. .r u.
To add, I think what we're seeing is a rift between intention and use. The way I see it, it's a weird convention because it's not used as I believe it was originally intended. And these days I'm striving for better readability so I'd consider it a good thing to not have my code riddled with periods meaning "print" in a way that violates more common conventions ... like using it as a sentence ender, or a decimal point, or an object-member delimiter. Dot-as-print is just a weird convention and not one I enjoy explaining to non Forth programmers.
> beginnings of Forth. So are .r d. .r u.
Also, note that in F18, . means "noop". There's no physical law that the period symbol has to mean "print" all the time.
0 new messages