Gauging interest - Platforming Engine

A losslessly-saved fixed-point format.

Can you give details on this point? Thanks.

Sure. This was a format I originally thought of for PTC, but didn't end up realising it outside of a proof-of-concept. Basically, each pixel will be split into x sub-pixels in terms of SBPE coordinates. That 'x' can be changed by the game developer. Ideally I'd default it to something like 4, but I'll keep it to 1 by default to avoid confusing first-time users (resolution 1 would make SBPE coordinates equal to pixel coordinates). Internally (and actually, externally too) SBPE will work ONLY with integers. This has several advantages over floating-point values: * Can be perfectly converted to string (via CHR$) and sent via local multiplayer in a future version * All math will be integer math, which is hopefully faster than floating-point math * None of those pesky round-off errors I hate so much There are, of course, some disadvantages: * Users of the library might not understand why setting a velocity of 2.5 is the same as exactly 2 (for example), before reading the documentation. * Accuracy is limited to the resolution you have chosen. If you suddenly find you need more accuracy, you will have to change just about every number you used in your program :( Personally I think this choice is a smart one, and I'm pretty sure this was how many games worked on NES. The original purpose of this design choice, for PTC, was simply to be saveable. I was limited to a 256-char string for saving, and needed the saving and loading to flawlessly recover the game state. Having all my values as integers was therefore a necessity, but having a velocity of 60 pixels per second per axis as the absolute minimum after 0 was way too fast, so I split the pixel length into 4 sub-pixels and found the resulting minimum velocity to be acceptable. I did the math with other things (coordinates, type, HP etc) and I had enough room for all my stuff! Sadly, I never made the game a reality :( In SBPE, you don't have to use a power of 2. A resolution of 5 will work just as well.

I wonder if it would be worth returning values to the user as predivided floats? Same for the values passed as parameters, just convert back to fixed point using multiplication. Then the users can set the resolution and just forget about it. Operations such as addition and subtraction would cause no roundoff errors (at least if the resolution is a power of 2). Either that or you can make wrapper functions that do the conversion, and keep the fixed-point interface available. For example, you can put a % at the end of function names that accept/return fixed-point values, or a # for floating point (or both).

Well, it turns out I have a lot less free time than I thought. My job has become a lot more demanding, and a course I'm taking started giving a lot more homework. :( Still, I managed to get a small start. It's not usable yet, hell it's hardly anything, but I hope it shows I'm not all talk and no action:\ http://pastebin.com/GtbvfQmQ Sadly, I don't think PasteBin has any syntax highlighting that would play nice with SmileBASIC, so you can either try to read it like that (good luck) or copy it to a text editor that does. Here's my hastily-made syntax highlighting for Notepad++: http://pastebin.com/cxGehpDZ download it as .xml, open the Define your language... dialog in NP++, click Import and choose the XML file. Alternatively use SynWrite with this: http://smilebasicsource.com/page?pid=54 Personally I prefer not to use the font, even though the user-defined languages allow you to set a font.

A little bit of progress. Still nothing usable, just more backbone. http://pastebin.com/HayGA7nS Just posting this to remind people to nag me to finish this already :P