Official PROSONIC Topic

Wow, lots to respond to!

I've side-stepped this because it conflicts with the ProSonic strategy. My plans are to move as many people away from MMF, writing custom engines, and ROM hacking as I possibly can and get people to use this engine. I want this to be a solution for all. It'll never replace the research and discoveries of ROM hacking, but it will do everything people expect from a Sonic game engine.

If I make it so level data can be taken from ProSonic back to a ROM, it makes it harder to achieve this. Plus since ProSonic uses more advanced tile method (as far as colors are concerned), it would be very difficult to take it backwards to the ROM.

They'll be fully constructed images. For technical information on the sprite format currently being handled by ProSonic, visit my other topic. It combines animations and sprites into a single file.

Sprites will be done in an 18-bit color format. Depending on the mode ProSonic runs in (8, 15, or 16-bit color) will determine how they will look on the screen. With the ProSonic sprite format, you are allowed to have a maximum sprite "sheet" size of 32767x32767 (very large). In addition, depending on how the art is arranged on the sprite sheet, it can be optimized for space by sharing previously used art data. So it's really only limited to what you can get on the sprite sheet. But the chances of anyone maxing out the sprite sheet aren't very high at all.

You're limited to 65535 animations per sprite file, and each animation can have up to 255 frames. Animation speeds can range from 16.67ms (1/60 -- extremely fast) to 4.25s (255/60 -- extremely slow). There's plenty of flexibility in the sprite/animation department

Currently the limit is 128. That's for just one player... I'll either split it for multiple players, or I'll increase it for multiple players. Obviously the more objects allowed on the screen at once, the more memory that is required. 256 bytes are used for this, so there's plenty of room for expanding if needed, that is if the processor can handle it without slowing down.

I'm hoping you're right =) I want a good sprite editor myself.

I'm not sure what you mean by chunks... I'm 'guessing' you're refering to the 16x16 blocks. ProSonic calls them "blocks", but I suppose there's not really any correct terminology for them since they're not quite tiles and certainly not sprites.

In the original Sonic games, there were 3 steps -- 8x8 sprites, 8x8 sprites coming together to form 16x16 blocks, and then 16x16 blocks coming together to form the level tiles (either 256x256 or 128x128).

ProSonic uses only 2 steps -- the art for the tiles is done entirely in 16x16 blocks. These are fused together to create the level tiles. The level designer has a choice of what size he/she wants to use for the particular level they're working on. ProSonic supports 256x256, 128x128, 64x64, and 32x32 tiles. I wanted to do this because various people I've spoken to during the development of ProSonic have different opinions. Some people like smaller tiles, while others like larger tiles. So I figured it'd be neat to allow the level designer to pick what size a level should use.

As far as being limited to how many tiles or blocks are available, ProSonic addresses up to 14-bits for blocks. This is 2 more bits than the Sonic games for Sega Genesis. 14-bit allows you to have 16,384 blocks to use. ProSonic also allows you to have up to 65535 tiles. Now of course these numbers are insane, but I am allowing this much flexibility to ensure that people can do everything they could ever possibly want to do with the engine.

And don't worry about having to construct those 16x16 blocks by hand. It's optional for advanced users, but my "EZ Tile" utility can read a fully drawn tile from a image file on your hard drive, break it into 16x16 blocks, import the blocks, and construct the mappings all for you. So it's made to be easy.

The engine uses tiles to construct the background just as the Sonic games on Sega Genesis did. But you can draw a full background and use EZ Tile to break it up into seperate tiles for you.

ProSonic uses 3 'true' layers, but it simulates paralax scrolling using a filter. The 3 layers are labeled L, H, and B (low, high, and background). Sprites share these layers with the tiles.

The filters use what I call 'cells'. A cell is basically a virtual layer that allows you to select what area of the background to draw in it, and apply attributes to each cell to create scrolling effects and such.

EZ Tile will help you out a lot!


Thanks for the questions!

 

In reply to Ultima, this engine will be able to be used to make non-Sonic games. ProSonic is the name I'm using to promote it in the Sonic community since that's where my focus is. But that's not to say it couldn't be used to make a Mario game or something. The physics and such will likely be put into the scripts. The only thing that would be built into the engine itself would be the constants used for the calculations.

In reply to ICEknight, the reason I call it a more advanced tile method isn't to make it sound hyped. What it means is because you have a 256 color palette with 16x16 blocks able to use ALL the colors in the palette, it makes it hard to accomodate for this. The Sega Genesis would only allow 16 colors per sprite, which is far less than 256 (or 32k / 64k for high-color modes). It's true I could have a Genesis simulation mode where the tiles and such would act like the old games with the same limitations, but it's an awful lot of work for a feature I doubt many people would bother to use in the first place. But again, I don't want ProSonic to support ROM hacking, I want it to do the opposite.

 

Yep, and for one big reason -- Sonic CD and Knuckles' Chaotix use sprite scaling (don't remember if they use rotating, but this will be supported too). Scaling will have to also be supported since my engine has the zooming feature. It wouldn't make sense to zoom in and out of the level without applying the zoom to the sprites as well.

And sprite rotating will also be supported. The engine will support up to 256 rotation angles. At one point I thought about allowing the entire level to rotate. This would be an interesting feature that could be used in many different ways, but I am not sure that it's really necessary... will people actually WANT to rotate their levels for any purpose at all?

 

I thought of that, but I think people would get headaches after a while.