LocalH, on Mar 10 2008, 08:06 PM, said:
http://www.sys2064.com/emudx.htm
All we need to do is do this with a MD emulator, and then make the art packs. There's also no real limitation on the pallet - if you're replacing MD tiles with external ones, then those external ones could be anything - even 32bpp RGBA PNG. Sure, it might add CPU consumption over top of the emulator itself, especially if you
were to use 32bpp RGBA PNGs and thus required alphablending, but I don't think that'll be a problem for most modern computers (and you could always have more simplified 8bpp tiles as well for slower computers). The only possible issue I could see would be supporting tiles that, on the MD side, use multiple pallets throughout the game - but then again the emulator could check for that and either load the same upgrade tiles with a different pallet, or load entirely different tiles (imagine having EHZ and HTZ with the same basic feel but with subtle differences in the tile art, which would give each zone a little bit more of an independent identity instead of HTZ being "the EHZ clone with a few slight differences").
On a tangent, the same thing could be done but instead of generating a 2D image, the emulator peeks the game's RAM and generates a suitable 3D scene (what I like to call 2.5D, sort of like the Smash Bros. camera angle). This would be more work of course, and each individual game would have to have separate support (the S1 support could be used as a base for S2 and S3/S&K though).
I'd be happy to see both of these happen, and I'd also be willing to test them to make sure that nothing is broken. I'd expect to see the former way before the latter, but either one would be fucking epic.
That would be beyond awesome, and exactly what would be needed for this. Now, do we have anyone here up for the job? As soon as someone was to make something like this, I'd get right onto making high definitions of levels.
Rolken, on Mar 10 2008, 08:30 PM, said:
Vangar, on Mar 9 2008, 10:51 PM, said:
It wouldn't need mad skills. It would just need a similar engine to sonic 2, a feat I've seen most of the coders reprogram in C or something.
You're either vastly overestimating the resources available to you, underestimating what it is you're asking, or both. An excellent full-time coder might be able to pull off an engine and the necessary utilities to power it in 1-3 months, and you're dealing with a community of technically adept but still inexperienced enthusiasts, hardly any of whom have ever actually worked on a real game development project. Every Sonic engine project I know of that's got anywhere has required at least one rewrite cycle, so unless you get somebody sufficiently motivated to spend their whole summer coding for you and they know exactly what they're doing from start to finish, I would be popping champagne if finished code rolled off the production line before 2009.
edit: whoops, totally missed LocalH's post. Are there not any situations in which the game cycles palettes within a level itself (waterfalls)? But yeah, I would be surprised if using an emulator is not by far the superior option.
But im asking the full time coders that pop in here, im not really asking for a full community project with everyone pitching in. I think your overestimating what really needs to be done, drawn graphics don't need spectacular coding, and if we could manage to use, for example, a rewrite from Taxmans engine to support larger png files, really isn't that much, is it? (isn't it XG or something now too?) The emulator rewrite sounds like a good idea though. The waterfalls, when called for or used, could be replaced with a set of images depending on the call for each palette?
The N64 Emulator had it done, its not impossible. Once it was done (I didnt expect it to be created super fast), it really wouldnt only be me who would benifit from it anyway.
This post has been edited by Vangar: 10 March 2008 - 04:40 AM
Posted 12 March 2008 - 03:44 AM
