Official PROSONIC Topic

I made a topic, but I really wanted to focus on getting help for the sprite editor more so than discussing ProSonic, so I have made this topic. I'd just prefer a topic that starts out like this instead of asking for help in it's first post.

What is ProSonic? If you don't know, read my outline:
DOC - http://www.comprosoftware.com/saxman/outline.doc
PDF - http://www.comprosoftware.com/saxman/outline.pdf

What does ProSonic look like in action? Here's some videos:
03/13/2007 - http://www.youtube.com/watch?v=YXi_WOHXalE
01/07/2007 - http://www.youtube.com/watch?v=oy2K_4KDeLI

News on the engine generally made at my blog -- http://dgrove.blogspot.com/



Okay, now time for new info. Recently in my spare time (when I'm not outside riding my bike and stuff like I've been making myself do), I've been adding a high-color mode for ProSonic. The engine since the beginning has always used 8-bit color. Now it supports 15-bit and 16-bit color. Here's a list to give those who don't know the technical side of it exactly what this means:

8-bit (256 colors)
- 16 X that of the Sega Master System
- 8 X that of the Sega Game Gear
- 4 X that of the Sega Genesis

15-bit (32,768 colors)
- 2048 X that of the Sega Master System
- 1024 X that of the Sega Game Gear
- 512 X that of the Sega Genesis
- Equal to that of the Sega Genesis 32X

16-bit (65,536 colors)
- 4096 X that of the Sega Master System
- 2048 X that of the Sega Game Gear
- 1024 X that of the Sega Genesis
- 2 X that of the Sega Genesis 32X

Games like DOOM run in 8-bit color. Other games like (insert game here) run in 16-bit color.

Okay, so why did it take so long to incorporate 15/16-bit color modes into ProSonic? It wasn't easy, because I wanted to keep backwards compatibility. I want a person to be able to create a level in a game that runs 16-bit color, and then be able to put that level in a game that runs 8-bit color without any issues... and vise-versa. So I had to go and change the format of a lot of data files used by my engine. I had to rewrite large sections of the drawing code to get it working. It required a whole lot of brain-storming and planning, but it works now.

In addition, I'm allowing level designers to setup levels with these variables:

char ForcePaletteTiles8;
char ForcePaletteTiles16;
char ForcePaletteSprites8;
char ForcePaletteSprites16;

These are basically 'modes' you can use for levels. "Force Palette" refers to making the game use a color palette index value, regardless if the palette index is close to what the color is supposed to be or not. This essentially allows you to change the color of the tiles by simply changing the palette. You can have it do this with tiles and sprites, in 8-bit and 15/16-bit modes.

However, when the "Force Palette" is disabled, it has a different effect. Here's the effect it will have based on what color mode is being used:

8-bit -- first check the palette index value of the pixel to see if the RGB value of the palette index matches that of the RGB value in the graphic data. If it matches, draw using that index. If it doesn't match, do a trial-and-error run on all the colors to see which index value has the closest match to the RGB value being sought.

16-bit -- just use the freakin' RGB value and ignore the palette. In fact, we don't even NEED a color palette for this mode.



Now the 8-bit method is important. This addresses another compatibility issue. In the water levels in Sonic games, sometimes the same color at two or more locations in the full 64 color palette is given two very different water color translations. This shows up in ProSonic when using Chemical Plant -- the yellow turns a very ugly color when using the water map on it. The 8-bit method I came up with allows it to know exactly WHICH index value to use for the color. That way it will always use the correct index value for the same color so that it correctly translates underwater.

There are benefits for each of the modes. 8-bit draws faster than 15/16-bit, but effects such as translucency is tons faster in 15/16-bit. I guess if computers had maybe 1000 X the RAM they do these days, it might be possible to make translucency fast in 8-bit, but that's just not realistic at this point in time. So it depends on what you want out of your game. 8-bit performs better under most conditions, but 15/16-bit handles special effects with more ease. If desired, ProSonic will allow the player instead of the designer to decide which mode is best for them.



To some of you this doesn't sound like much, and I understand, but this was actually a very big step in development. It's important to get these formats squared away. The next task would be to try (again) to get scripting working in ProSonic. I'm currently in talks with the AngelScript designer in hopes to get the thing to work right. It will be beneficial to the engine. I have got suggestions for 'other' script libraries to use, but for the moment AngelScript appeals to me more than any of the rest.

Then my plan is to get some of you guys to design objects for ProSonic! Hopefully with a working sprite editor and an understanding of how to script, it should be fairly easy. I've already designed rings, springs, and a few test objects. I don't want to write a bunch of objects myself though. The only object I plan to do is Sonic. I will not begin the player code until scripting is fully functional. The old engine incorporated the player into the engine source code itself, but I'd like to steer away from that this time around and stick to using scripts.

 

With all due respect, it hasn't a thing to do with ROM hacking! The only thing related to ROM hacking is that you can port levels and other data from Sonic Genesis games over to ProSonic, but that's it. ProSonic is it's own thing.


Oh and on the PSP port, I hope this can be done, though I'm much more interested in a Nintendo DS port personally as I doubt the PSP is going to go very far.

 

The outline explains it in very heavy detail and describes the differences. But I think perhaps the real confusion for you is "what exactly is a game engine??"

These games I'm going to use as examples are older games, so I don't know how familliar you are with them... DOOM, DOOM II, Heretic, Hexen, Strife -- all those games use the "DOOM Engine".

Another example is Sonic the Hedgehog, Sonic 2, Sonic 3, Sonic & Knuckles, Sonic CD -- all those games use the "Sonic Engine".

ProSonic is another engine. It is going to have all the features of the Sonic engine, but with lots more added on top of that.

 

LOL I like the text! Yeah this is a neat concept. My goal is to allow ProSonic to support up to 16 players, so you could actually have even more than you have shown. But realistically, I would imagine it'd be rare to see all 16 on the screen at one time.

And old old OLD idea of mine (like from years ago) was to have an interactive community through netplay! Like actually have different characters that people could customize and walk through a big city level. It would be a gathering where you'd meet other players. You could see other players walking around the city, and there would be activities there and such. Then you could chat with each other and join a game even. I don't know that I'd do something like that with ProSonic though. But that's what your pictures remind me of! =)