next »

[rogerlevy]

Alright, this is Post 2.0.

I am working on a library for programming games in the Forth language. 

Forth offers many advantages.  Its syntax is easy to learn and offers the same degree of control as Assembly while allowing high-level abstractions.  One of its fundamental tenants is specialization to what you want to do.  Once you get the hang of reverse polish notation and the idea of creating your own language constructs, productivity gains are huge.  Case in point: this iteration of my library has been in development since mid September. So the features you'll see listed below took 3 months to code.

I am developing it on SwiftForth for Windows XP.  Porting to other Forths and platforms is planned.  Windows Vista and 7 compatibility is especially greatly desired.  SwiftForth has a good set of debugging tools, documentation, and OOP support.  There is a Trial version that can't produce executables, which my library is designed to still be useful with.  To run programs created by non-licensed coders you only need to download and install SwiftForth. And, there are plans to create a kind of data-driven game engine in the future.  This means, so long as you don't mind sharing your source code, you don't have to buy the full version of SwiftForth to try the library.  And finally, ports to free open source Forths like GForth and Win32Forth are possible,  depending on interest from the Forth community.

Forth has a lot of bad rap for being too low-level, and not having enough high-level facilities like in other languages.  My library also addresses this very real problem by providing a cornucopia of convenient high-level structures to make programming more convenient.  Here is a list of the ones that exist so far:

• Single and double linked lists
• Stacks
• Object pools
• High performance heap
• Fixed point math
• Fixed point vectors
• Matrix math
• Quick-sort
• Quotations (inspired from the Factor language) - enables very convenient callbacks.
• C-style structs
• File access convenience words
• Bindings to OpenGL, including support for OpenGL extensions
• Bindings to SDL, Sprig, FMOD, DevIL, more

On top of these, I've built a solid foundation for games programming, and what's yet to come in Quest.  Here's a rundown:

• Relies on OpenGL and SDL so you get all the power of both.
• Robust 2D support while being programmed with future support for sophisticated 3D games in mind.
• Included sprite and tile editor (in development).  Has animation and palette support!  I intend it to be superior to all other similar tools (with the exception of maybe Pro Motion.)
• Mouse and keyboard input with a very convenient syntax and advantages over plain SDL such as compensation for the screen resolution and aspect ratio in regards to mouse motion.
• Bedrock for sorting state to avoid unnecessary calls to the GL.
• Collision detection routines for Rectangles, Points, Ellipses, and Circles.
• Highly optimized tilemap, sprite, and text drawing modules. (Benchmarks on my machine, numbers are per 60hz frame : Tilemap - 150,000 tiles; Sprite - 100,000 quads; Text - up to hundreds of thousands of characters if you use static vertex buffers.)
• Fontrast font converter allows usage of any truetype font.  (Note: Since Fontrast is not free some other equivalent tool can easily be supported by tweaking the converter; any suggestions welcome.)

• OpenGL-based 2D drawing module - simple primitives such as rectangles, lines, ovals, even textured rectangles.  Programmed for convenience over speed.
• Support for any image format thanks to DevIL the image library.
• Vertex buffer support.
• Convenient vertex array building keywords, allow efficient vertex array/buffer creation using a syntax similar to OpenGL's immediate mode.
• Statically-compiled data feature allows you to easily embed all your data into your executable (currently requires full version of SwiftForth).  Loading time greatly reduced as there is NO lengthy unpacking stage like with Game Maker. 
• High performance cooperative multitasking system that makes many time-based features (such as dragging and dropping, tweening and A.I.) much more convenient to code. Full control over multiple nested rings and turning tasks on and off is supported.
• Texturebank system for packing many sprite or tilesheets into one large texture at runtime.  Can reduces texture bind calls for increased performance.
• Flash-style Tweening! Many equations included.  Equation API is very simple and MUCH more efficient than Flash.
• Convenient wordset that allows SDL surface manipulation using a simple API - features include basic primitives and flood fill. All the power of the high performance drawing library Sprig is available.
• Convenient benchmarking module.  Timing your code is as simple as typing "benchmark:[ <code goes here> ;]" or even simpler, "benchmark <routine>".

There are many planned future features:

• Convenient sprite animation - coming very soon.
• GUI module. This library was intended to help with building tools as well as games.
• Physics module using the Open Dynamics Engine.
• SSE-based high performance 3D math.
• More collision routines including 2D and 3D models and pixel-perfect collisions.
• Data-driven simple game engine for rapid prototyping.
• Cool editors and API's for future data formats.

I've been obsessed with this for 10 years.  This is my latest and most successful attempt at leveraging Forth for games and I've put a lot of time and thought into this so I want to share the fruits of my hard work (besides just enjoying it for myself).  You can check out my blog for news and history.  Link

I've also put up an SVN repository on Google Code.  This project is fully open source.  Link

The status of the library is alpha. Bugs exist and API is not set in stone. If you just want to try out the code, you can download a snapshot which I will update perhaps bi-weekly.  Download

Forth was once very popular in the 70's and 80's but was overshadowed by C, being the winner in performance.  However today Forth is usually compiled to machine code (SwiftForth) so now performance is extremely close to C and can even be better with good coding.  Information on Forth today often frames it as either irrelevant or not powerful, rife with trivial examples and emphasis on what it does not have as opposed to what it does.  Part of its advantage is its simplicity.  Part of its disadvantage is the fact that it is a bit stuck in the past.  I *hope*, that one day this language I believe in fervently will gain the understanding it deserves, as I think it is still relevant today and an absolute joy to use, being my favorite language ever with ActionScript 3.0 being a close second.   If you like assembly, you will love Forth.  If you have never programmed before, Forth is an awesome beginner's language.

For the best way to learn Forth, go here: Link

To step up your Forth chops, go here: Link

Thank you for looking and I hope my library interests some people.

[John Nesky]

What distinguishes this library from others is the fact that it is written in the least-understood programming language of all time, Forth.

That should be the first sentence of your post.

[Kekskiller]

At first I was totally confused what the fuck this it until I read the "Forth".

Well, I got interested and thougtht Forth is a cool, simple system - why don't give it a try? Does it work with other Forth systems, too? I mean, SwiftForth is like over 300$ and you're using it?

Sounds more like something to program microcontrollers. However, Forth itself sounds pretty cool. I need to implement it as a scripting language for my game!

[rogerlevy]

What distinguishes this library from others is the fact that it is written in the least-understood programming language of all time, Forth.

That should be the first sentence of your post.

Seriously? Should I move it?  I'm always worried about writing posts that don't "pull you in" well enough.

Edit: Duh! Of course I should. So I just did.

[rogerlevy]

At first I was totally confused what the fuck this it until I read the "Forth".

Well, I got interested and thougtht Forth is a cool, simple system - why don't give it a try? Does it work with other Forth systems, too? I mean, SwiftForth is like over 300$ and you're using it?

Sounds more like something to program microcontrollers. However, Forth itself sounds pretty cool. I need to implement it as a scripting language for my game!

SwiftForth has the ANS Forth wordset , so technically, the other Windows Forth's like GForth and Win32Forth and VFXForth are "supposed to be" compatible.  I'm using a few of SF's special features though so, practically, SF is it right now.  I *will* get it ported to other Forth's , or make it easily portable, eventually.  It's not hard (relative to something like C++) just  time consuming.

Yes it has a niche in programming microcontrollers but SF was designed to write Windows apps.  It has OOP extensions which are sadly non standard because OOP in Forth has not been standardized yet.  One good reason for me not to make use of it in my library, so it's a flat C-like procedural API.

I mean, SwiftForth is like over 300$ and you're using it?

Well, yeah, but I didn't pay for it. I use the full version of SF because I'm special.   :D  They gave me a license to continue using SF so that I could help find bugs and contribute my own code.  I've found few bugs (there's one nagging one but I'm not sure it's SF or me) so it turns out I just built my library on it and I get to make EXE's as a side bonus.  Again, I don't think SF should be the only target language but for now it is because at the time I thought it's documentation was the best.  GForth is my second best choice right now, though, VFXForth is the fastest, BUT, that one is even more expensive I think. (Again it has a fully-functional-minus-compiling-EXE's trial version.)

Argh!  Scripting??  Everyone's first reaction is that it would make a good scripting language.  You can use it Forth EVERYTHING now, man.  That's why I wrote this library!!    I was going to implement a BASIC-like scripting language because I thought Forth was too esoteric but honestly, I decided after writing so much Forth code using my latest conventions that I decided I liked it just fine to use for programming the actual games too.  It's not a big deal to extend the compiler to do some safety checks for you, especially if you keep the Forth syntax.  For good programmers with an open mind I really do recommend Forth.

[Kekskiller]

I just said scripting language, because the implemention/parsing is really simple. That makes it a) fast and b) flexible in terms of functionality. And I really don't want to code my engine in Forth. Especially because C++ offers a lot more syntax/code features than Forth (I also love crippled OOP without class derivation shit).

[rogerlevy]

I just said scripting language, because the implemention/parsing is really simple. That makes it a) fast and b) flexible in terms of functionality. And I really don't want to code my engine in Forth. Especially because C++ offers a lot more syntax/code features than Forth (I also love crippled OOP without class derivation shit).

Yes, that's the common reason for wanting to use it for that.   I would say that Forth does offer a lot of productivity boosts over more verbose/complicated languages like C++.  But if C++ is what you've gotten used to and feel productive in and you think Forth can help, by all means, don't let me stop you!

[rogerlevy]

*BUMP*

Wanted to take another shot at this without starting a new thread.

New OP.  Now with BULLET POINTS.   

[increpare]

And, there are plans to create a kind of data-driven game engine in the future.  This means, so long as you don't mind sharing your source code, you don't have to buy the full version of SwiftForth to try the library. 

But we do need to have it for now? 

*downloads and installs the trial anyway, just for a giggle *

[rogerlevy]

Nope, you don't, the library can be used to create programs that can be launched with a batch file or by dragging your main source file into the SwiftForth program icon.  During your development you can drag the file into the SwiftForth window, OR, use RUN, part of my custom terminal toolset, which I just uploaded to the google code page.

[increpare]

"can't find function TtyType in library TTY.DLL" when I try to launch scaffold (or any of the others).

[rogerlevy]

Copy them from your SwiftForth\Bin folder.  Scaffold is not very exciting; it's nothing but a grey screen; boilerplate for a program.

I still have to code a demo.

[increpare]

Copy them from your SwiftForth\Bin folder.  Scaffold is not very exciting; it's nothing but a grey screen; boilerplate for a program.

Ah ok that works now.  Grey screens all round.  Hurrah

I still have to code a demo.

Oh okay.  I'd like to see one when you have one done.  Forth is a somewhat-foreign language to me, so I'd like to see how someone with more experience goes about doing stuff in it.

[rogerlevy]

Good to know.  Yeah - I really think that it needs a demo.  I'll post here and on my blog when it comes out.

[increpare]

Good to know.  Yeah - I really think that it needs a demo.  I'll post here and on my blog when it comes out.

good.

[Hima]

I've never heard about Forth but this really got me interested. Also good thing you revise and rewrite the first post because I read this topic earlier and couldn't make out what so special and alternative about this library is.

[rogerlevy]

Thanks. Yeah the old one was too ... austere ... so I rewrote it.  And look! You're interested! 

I expect at this point all I'll get is interest; people first have to learn Forth and then how to use SwiftForth and THEN they can start using the library - or maybe all at the same time with the help of a tutorial.  But I figure at this point, the more people that know about it, the better.

Cheers and if you happen to get the idea to dive into it, don't hesitate to post here any problems you run into or questions you come up with, I will answer questions or fix issues as soon as their brought up to me.

[Triplefox]

I'd love to try this sometime - Forth is near the top of my list of "awesome languages I'd like to learn soon" but other priorities, like shipping the game I'm working on, are getting in the way. I really admire how tight and concise you can make the code. And I've read that engineers at Atari built games in Forth back in the "good old days" so it's not like this is unprecedented.

On the other hand, I'm a whore for things like type systems, garbage collection, and built-in data structures. Factor is the most obvious extant choice for combining the two, but that language comes with a lot of extra baggage - it looks more like a Lisp system with concatenative syntax than an extended Forth.

If you asked for "what feature would be most important to me" in a Forth-based gaming platform, I would say data pipelining and tools support. Game engines themselves traditionally aren't very feature-rich - they take relatively simple execution models and then blast tons of data through. Once you've got the model down pat and things are moving around the screen and interacting, most of the challenge comes from how to manage that data and create content to sustain a multiple-hour experience.

[rogerlevy]

Way ahead of you.  My graphics editor can edit any normal image but also can use an extra  file to store sprite and animation data.  And it's specifically for creating sprite sheets and tilesets, unlike other programs which seemed to only have been designed to make animation strips and animated gifs.

Automating the process of getting the data into the game is also something I'm going to concentrate on sometime down the line.

I agree those things are nice.  I think Forth is better than Factor because it is easier to master it.  I Love C# and AS3, but from a certain perspective, those things just get in the way.  Except for high level data structures.  Those can really simplify your job.  Forth really spoils me with how easy it is to write, refactor, and change the behavior of functions.  It just takes less time and typing.

Engine development can also be accelerated.  I've been tinkering with ideas that will remove some thinking from the developer's workload.  However, right now, I'm just trying to get that foundation down where you can make games at all, and that they'll work on other computers.  The really cool workflow-optimizing stuff will come gradually.

[Hima]

Is there anyway I can start learning this for free? SwiftForth cost $395 and I don't think I'm ready to pay that amount of money for experimentation