[jman2050]

There's pretty much no chance the code will be open-source while it's being worked on. After completion I want to make the code available, but letting anyone add to it at will is just going to complicate things and waste time.

[Cooljerk]

Yeah, and not to be a dick or anything, but I've been working on my NeedleMouse engine for a while, and while it might go open source one day, I'm not ready to let it out of my protective wing.

Like jman2050 said, maybe later down the road but for right now, I'd prefer not to. Which isn't to say people can't help, I just don't want the code being spread around just yet.

[Blue Streak]

I'm cool with things being closed source as long as the programmers are able to meet the needs of the project with their own skills.

[drx]

SANiK, on Apr 25 2008, 04:24 AM, 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

The thing is, the goal of this project is to produce a port of the game, not emulate it with dynamic recompilation.

Why not go with FLAC, instead of Ogg? FLAC is lossless, free, open source and royalty-free. It also offers a good compression ratio. Surely, for a HD port, you'd want to best quality possible?

[muteKi]

I dunno. I can't really tell the difference past 192k anyway. I also have less than 20 gigs on my HD (I can probably free up some, but not a lot).

[Blue Streak]

drx, on Apr 25 2008, 01:35 PM, said:

SANiK, on Apr 25 2008, 04:24 AM, 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

The thing is, the goal of this project is to produce a port of the game, not emulate it with dynamic recompilation.

Why not go with FLAC, instead of Ogg? FLAC is lossless, free, open source and royalty-free. It also offers a good compression ratio. Surely, for a HD port, you'd want to best quality possible?

If we deem that space isn't an issue, then certainly lossless compression should be used, although Slaituk is right and the reduction in quality is pretty much transparent to human ears past 192 kbps.

[Damizean]

Save your time and use the Sonic 2 mobile java disassembly.

This post has been edited by Damizean: 25 April 2008 - 01:55 PM

[drx]

Blue Streak, on Apr 25 2008, 08:38 PM, said:

drx, on Apr 25 2008, 01:35 PM, said:

SANiK, on Apr 25 2008, 04:24 AM, 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

The thing is, the goal of this project is to produce a port of the game, not emulate it with dynamic recompilation.

Why not go with FLAC, instead of Ogg? FLAC is lossless, free, open source and royalty-free. It also offers a good compression ratio. Surely, for a HD port, you'd want to best quality possible?

If we deem that space isn't an issue, then certainly lossless compression should be used, although Slaituk is right and the reduction in quality is pretty much transparent to human ears past 192 kbps.

Using the same logic, we could use JPG as the container for graphics, with 97% quality. I mean, it's almost the same, right?

If the project is going to be HD (high definition), it would be nice if someone with a good audio setup could listen to the music without the "mp3 feel". It doesn't really make a big difference size-wise, but it adds a nice touch.

After all, shouldn't we go for the best quality?

[Vincent]

I completely agree with DRX about that.
Why aiming low? We need to have the best audio possible on Sonic 2 HD.

[Blue Streak]

drx, on Apr 25 2008, 05:28 PM, said:

Blue Streak, on Apr 25 2008, 08:38 PM, said:

drx, on Apr 25 2008, 01:35 PM, said:

SANiK, on Apr 25 2008, 04:24 AM, 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

The thing is, the goal of this project is to produce a port of the game, not emulate it with dynamic recompilation.

Why not go with FLAC, instead of Ogg? FLAC is lossless, free, open source and royalty-free. It also offers a good compression ratio. Surely, for a HD port, you'd want to best quality possible?

If we deem that space isn't an issue, then certainly lossless compression should be used, although Slaituk is right and the reduction in quality is pretty much transparent to human ears past 192 kbps.

Using the same logic, we could use JPG as the container for graphics, with 97% quality. I mean, it's almost the same, right?

If the project is going to be HD (high definition), it would be nice if someone with a good audio setup could listen to the music without the "mp3 feel". It doesn't really make a big difference size-wise, but it adds a nice touch.

After all, shouldn't we go for the best quality?

I was under the impression that we were rendering the tiles as PNGs, and then the color data from those was being programmed directly into the engine somehow, making the format for graphics storage ultimately proprietary. While we're debating quality though, I'd like to point out that Blu-ray uses both lossy video and audio codecs, as does HD quality TV. So we should optimize both quality and space.

[drx]

We don't need to have the same definition of HD as television and BD movies do.

[muteKi]

I always assumed that the HD name was just 'cause it was simple and meant higher-quality, not necessarily to a specific standard.

[Overlord]

"HD" can refer to one of about 12 bazillion resolutions =P

[Tweaker]

Exactly. In fact, I'd even prefer if the game wasn't at 4x—2x, and even 3x are perfectly acceptable upscaling ratios, widely acceptable to most PCs (which tend to use 1024x768 as the minimum standard). Plus, I don't have a 1280x1024 screen resolution (I'm stuck at 1024x768), so I think 3x is probably the most reasonable to everybody, even though I still think 2x is fine. That's the resolution all my Genesis emulators are set to use, after all. :P

[SANiK]

What hasn't been decided is if they're going to split the sprites into tiles or not.
I mean - if they want to keep tiled sprites - then get ready to have a blit function at hand
I'd have them go with using non-tiled sprites and each frame has a 'center'-offset

But for the levels, it's best they keep Sonic 2's 128x128 chunk tile groups
So one can keep each tile group as separate textures and draw them out using less polygons compared to drawing a polygon (quads) per individual tile.
If you planned on blitting each tile onto a SDL surface - it might be interesting to see a speed comparison

This post has been edited by SANiK: 26 April 2008 - 11:10 AM