[Athelstone]

***PROGRAMMING UPDATE: 12OCT08***

Resulting with the actual Tech Demo, we already estabilished the S2HD "Programming Team"

At this development stage we don't need other programmers
*Any additional required programming positions will be officially stated when needed*


Thanks!
-S2HD Staff

This post has been edited by Vincent: 11 October 2008 - 05:21 PM

[Armada]

Perhaps I could be of assistance. I don't know if I know enough C++ for this job, but I'll be waiting I you need me. Anyway, I think whoever gets chosen for this gets an epic win in my book. This is a challenge beyond any other.

[jman2050]

I can do this extensively later on, but not any time in the very near future. Too many other commitments to do.

Should give you some time to really get much of the other work done at least.

[Athelstone]

Quote

Too many other commitments to do.

I totally sympathise with that, RL matters should always take priority. Though it'll be interesting to se how this progresses. Don't forget to ask Taxman for advice and tips

[drx]

I am willing to help with the programming/engine/translation parts, after mid-May, if my help will be of interest. I'm more of a C than C++ person, but I have a lot of experience in dealing with the Sonic engine, M68K, the Megadrive hardware, doing mathematical stuff etc.

[Cooljerk]

So I'm already teamed up with hez to create a sonic engine in C++ based on my graphics engine and his sonic engine, but I'd like to contribute to the project.

I have a pretty nice graphics engine all coded up, using SDL. It's normally set to output at 320 x 240, but it could very easily output in a higher resolution. It works very much like the genesis, with a much bigger color palette, and allows for rotation, scaling, and skewing. I made a topic a long time ago about it, and I think it's still on here.

It's by no means complete, and I wouldn't be able to really work on it until my summer began (around 2 weeks from now) but I think it'd be perfect for this project. I can post more about it if anyone's interested.

EDIT: And I'd be willing to help out on other parts of the game, as well. And while my engine can't display normal genesis graphics natively, it wouldn't be hard to modify it to do so. All I'd need to do is sit down and examine how graphics in the genesis are stored.

EDIT DOS: And, since it's written in SDL, it supports ogg.

This post has been edited by Cooljerk: 24 April 2008 - 07:02 PM

[Overlord]

Out of MP3/OGG/VGM I'd use OGG for this anyway - VGM is too limited in terms of musical arrangements (you need PCM =P), and MP3 isn't designed to loop cleanly - OGG is - it's used a lot in the games field for this reason.

[Blue Streak]

Overlord, on Apr 24 2008, 09:02 PM, said:

Out of MP3/OGG/VGM I'd use OGG for this anyway - VGM is too limited in terms of musical arrangements (you need PCM =P), and MP3 isn't designed to loop cleanly - OGG is - it's used a lot in the games field for this reason.

I would most definitely support OGG over MP3 because I know Overlord is right and it sucks for looping. If anything, the Vorbis codec is a higher quality for the size anyway.

[Tweaker]

Well, I can render to OGG with my original source files, so that shouldn't be a problem. Getting the looping absolutely correct might take some work, though, since I've never done it before. Anyone experienced willing to handle that?

[Cooljerk]

Tweaker, on Apr 24 2008, 05:26 PM, said:

Well, I can render to OGG with my original source files, so that shouldn't be a problem. Getting the looping absolutely correct might take some work, though, since I've never done it before. Anyone experienced willing to handle that?

I've got experience with that.

[jman2050]

Athelstone, on Apr 24 2008, 07:01 PM, said:

Quote

Too many other commitments to do.

I totally sympathise with that, RL matters should always take priority.

Actually, it's a few other programming projects I had committed too earlier

Quote

Though it'll be interesting to see how this progresses. Don't forget to ask Taxman for advice and tips

If he's not on the project, why would I need to talk to him about anything?

[SANiK]

Err,

1) Go through the S2 disassembly
2) The parts that do graphics/audio dependent stuff like accessing tile drawing - replace with a different set of operations (special opcodes*)
3) Write a bytecode assembler that takes in the Asm text dump and produces simple byte code
4) Write a bytecode emulator

* = the special opcodes would be a direct way of sending info to the emulator, e.g.
drawTile x, y, $00001234
You get the point

I wonder what drx would say of this

This post has been edited by SANiK: 24 April 2008 - 09:26 PM

[Cooljerk]

SANiK, on Apr 24 2008, 06:24 PM, said:

Err,

1) Go through the S2 disassembly
2) The parts that do graphics/audio dependent stuff like accessing tile drawing - replace with a different set of operations (special opcodes*)
3) Write a bytecode assembler that takes in the Asm text dump and produces simple byte code
4) Write a bytecode emulator

* = the special opcodes would be a direct way of sending info to the emulator, e.g.
drawTile x, y, $00001234
You get the point

I wonder what drx would say of this

Wouldn't it be easier to port the sonic engine from the disassembly to a more modern programming language, than to rewrite all the graphics operations with special opcodes for a custom bytecode assembler which runs on a custom bytecode emulator? And more practical, too?

I mean, I see where you're coming from - the game would then play 100% accurate, but that seems to me like an obtuse way to do it.

[SANiK]

cooljerk - you're right but most of the stuff will have to be rewritten anyways.

E.g., no need for vsync timing to do palette effects to allow for more colors
Computers are powerful these days

I'd also go with using vectors/splines for collision data instead of using pixel maps
So this would require a rewrite as well

But another solution might be to just provide a flat-3D model of a map for use with the collision
And then a tilemap for the drawing

This post has been edited by SANiK: 24 April 2008 - 09:41 PM

[Cooljerk]

I've been talking to jman2050, and I've offered my graphics engine, NeedleMouse, to the project. NeedleMouse is almost complete already, but for the purposes of this project, I'm gonna need to make some changes to it (and I'd like to optimize it, out of practice). Before we get too deep into sprite creation and what-not, we should first come up with set rules for the graphics engine, and how it'll behave. Also, before I go any farther, I'd like to note that I'm completely open to criticism, and ideas on how to do things better or more efficiently.

I guess I'll start by describing how NeedleMouse works. NeedleMouse is written in C++ using SDL. It utilizes SDL_RotoZoom to handle scaling and rotation. The graphics engine is split into several pieces:

The core of the graphics engine is NMLayer. NMLayer encompasses an SDL_Layer and works a lot like a photoshop layer does. Individual graphics effects can be applied to layers separately. I.E. you can have layer1 apply a sin-wave effect like in Tidal Tempest Zone, while all the layers behave normally. You can create an unlimited amount of layers. You can also individually set the alpha for each layer, I.e. "50% alpha blending for this layer."

NeedleMouse also has a palette called NMPalette. NMPalette is a list of colors from which to draw from. I've currently got it set at 5 palettes with 64 colors each, but those numbers can be changed. I think I heard that someone wants 256 colors and 1 alpha... I could change it to 5 palettes of 256 colors each. NMPalette assigns a special color to the alpha, which I'll touch upon later. In addition to these 5 palettes, there's also an option to import a second NMPalette for scanline palette swapping. I.e. "after the 50th row, start drawing with the alternate palette." This lets NeedleMouse achieve similar effects the water effect from Sonic.

NMLayer draws from NMTileMap, which is made up of NMTile. NMTileMap is just what it sounds like - a collection of NMTiles. NMTiles are 64 bytes big, with each byte referring to a color index from NMPalette. You can think of them as 8x8 little sprite maps.

Sprites are arranged in TSR files - TheSonicRender, a format I created. TSR files are self-contained graphic objects. a TSR file contains info on how NMTileMap should be read to build a tile, and it contains info on how to build every frame of animation for an object. For example, say we took a picture of sonic and split him up into NMTiles, and lets assume for this example that Sonic is contained in 6 NMTiles. The TSR File for sonic would contain info on how to read from NMTileMap to arrange the NMTiles into the Sonic we all know and love. TSR files also contain information about how to animate the objects, I.e. "animation 1 is 5 frames long, which are frames X, Y, Z, A, & B, and on frame B, start animation 2." They also tell what default palette to use in NMPalette. I.E. "draw with palette 2." The sprite information in TSR files are stored using an array of chars, with the value of the char being the color index to point to in NMPalette. I.e. 'A' would point to color 65. If anyone has a better way to store color information, I'm all ears... this could be very easily rewritten to more accurately match the way sprites are stored on the genesis.

Palettes are stored as NPL files, which are simply arrangements of rgb values. Again, like the sprite info, these can be rewritten to more accurately match the way Sonic the Hedgehog stores it's palette information.

NMLayer can also pull from NMText - a text class which pulls fonts from a bmp file. It works as you'd imagine - you create a BMP file with every character you'd need, then assign XYWH coordinates for SDL_Rects inorder to blit them from the bmp directly to the NMLayer. This was originally a cheap trick I used to quickly get debug info from my engine, but it's stuck. I'd be up for rewriting it, but honestly it works fine (IMO)

Again, all this is flexible, and I'm willing to change anything that needs to be changed.

I think the first step should be to standardize the format. How many colors do we want, how many palettes do we need? I had NMPalette include 5 maps of 64 colors so I could do palette rotation without fucking up lots of different parts of the image. I.E. Sonic and the sky could share the color blue, with the same color index, but the sky could rotate without sonic changing as Sonic would use Pal1 and the sky would use Pal2.

What screensize should we use? It's currently set to 320x480, but it can very easily be changed. Should we have a limit on NMTileMap, or should something be handled differently? All this stuff will be crucial to figuring out what we can, and can't do with the images, and right now the limitations of the engine are flexible to what we need.

So feel free to comment or leave ideas.

EDIT: WHAT WE NEED TO FINALIZE THUS FAR:
-Number of colors
-Number of Palettes
-Screen Resolution

AIMS
-Scaling (Check)
-Rotation (Check)
-Flexible Palette (Check)
-Tiles (Check)
-Read original Sonic palette info
-Read original Sonic sprite info
-Mode 7 (partially implimented)
-Polygon rendering (very, very buggy)
-what else?

Oh, and I almost forgot - I've been creating, for a very long time, an image editor which makes it easy to create art for the engine. You can import an image of any format, and have it automatically convert it into a NPL, TSR, and TileMap files. You can also set and organize animations from the program.

This post has been edited by Athelstone: 26 April 2008 - 04:24 AM