Sonic and Sega Retro Message Board: All Programming Discussion - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 45 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last ►
    Locked
    Locked Forum

All Programming Discussion Graphics, Audio, Engine Design, etc.

#31 User is offline jman2050 

Posted 25 April 2008 - 11:09 AM

  • Teh Sonik Haker
  • Posts: 633
  • Joined: 10-December 05
  • Wiki edits:4
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.

#32 User is offline Cooljerk 

Posted 25 April 2008 - 12:20 PM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4120
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9
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.

#33 User is offline Blue Streak 

Posted 25 April 2008 - 12:32 PM

  • Posts: 691
  • Joined: 08-October 05
  • Gender:Male
  • Location:Tempe, Arizona, USA
  • Wiki edits:6
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.

#34 User is offline drx 

Posted 25 April 2008 - 12:35 PM

  • <Shade> fuck MJ
  • Posts: 2156
  • Joined: 02-March 04
  • Gender:Male
  • Project::rolleyes:
  • Wiki edits:8

View PostSANiK, 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?

#35 User is offline muteKi 

Posted 25 April 2008 - 01:07 PM

  • Fuck it
  • Posts: 7512
  • Joined: 03-March 05
  • Gender:Male
  • Wiki edits:91
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).

#36 User is offline Blue Streak 

Posted 25 April 2008 - 01:38 PM

  • Posts: 691
  • Joined: 08-October 05
  • Gender:Male
  • Location:Tempe, Arizona, USA
  • Wiki edits:6

View Postdrx, on Apr 25 2008, 01:35 PM, said:

View PostSANiK, 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.

#37 User is offline Damizean 

Posted 25 April 2008 - 01:55 PM

  • As classic as rock
  • Posts: 118
  • Joined: 01-February 06
  • Gender:Male
  • Location:Valencia, España
  • Project:Various projects
  • Wiki edits:1
Save your time and use the Sonic 2 mobile java disassembly.
This post has been edited by Damizean: 25 April 2008 - 01:55 PM

#38 User is offline drx 

Posted 25 April 2008 - 04:28 PM

  • <Shade> fuck MJ
  • Posts: 2156
  • Joined: 02-March 04
  • Gender:Male
  • Project::rolleyes:
  • Wiki edits:8

View PostBlue Streak, on Apr 25 2008, 08:38 PM, said:

View Postdrx, on Apr 25 2008, 01:35 PM, said:

View PostSANiK, 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?

#39 User is offline Vincent 

Posted 25 April 2008 - 04:39 PM

  • Sonic 2HD - Project Leader & Character Artist
  • Posts: 1253
  • Joined: 03-May 07
  • Gender:Male
  • Project:Sonic 2 HD
  • Wiki edits:6
I completely agree with DRX about that.
Why aiming low? We need to have the best audio possible on Sonic 2 HD.

#40 User is offline Blue Streak 

Posted 25 April 2008 - 04:42 PM

  • Posts: 691
  • Joined: 08-October 05
  • Gender:Male
  • Location:Tempe, Arizona, USA
  • Wiki edits:6

View Postdrx, on Apr 25 2008, 05:28 PM, said:

View PostBlue Streak, on Apr 25 2008, 08:38 PM, said:

View Postdrx, on Apr 25 2008, 01:35 PM, said:

View PostSANiK, 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.

#41 User is offline drx 

Posted 25 April 2008 - 06:24 PM

  • <Shade> fuck MJ
  • Posts: 2156
  • Joined: 02-March 04
  • Gender:Male
  • Project::rolleyes:
  • Wiki edits:8
We don't need to have the same definition of HD as television and BD movies do.

#42 User is offline muteKi 

Posted 25 April 2008 - 06:32 PM

  • Fuck it
  • Posts: 7512
  • Joined: 03-March 05
  • Gender:Male
  • Wiki edits:91
I always assumed that the HD name was just 'cause it was simple and meant higher-quality, not necessarily to a specific standard.

#43 User is offline Overlord 

Posted 25 April 2008 - 06:35 PM

  • Substitute Meerkovo IT Chief
  • Posts: 16498
  • Joined: 12-January 03
  • Gender:Male
  • Location:Berkshire, England
  • Project:VGDB
  • Wiki edits:3,204
"HD" can refer to one of about 12 bazillion resolutions =P

#44 User is offline Tweaker 

Posted 25 April 2008 - 06:35 PM

  • Posts: 12389
  • Joined: 27-June 04
  • Gender:Male
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

#45 User is offline SANiK 

Posted 26 April 2008 - 11:07 AM

  • Posts: 408
  • Joined: 21-September 04
  • Gender:Male
  • Wiki edits:6
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

  • 45 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users