Sonic Engine Demo

THIS.
You guys are aware that this is a port of the original Sonic engine and not just a clone, right? I'm fairly certain Pro Sonic is a clone. (And PLEASE Saxman if I'm wrong don't kill me, I only remember what you had when we first started)

And this is my fault, I was bugging him to put up a demo. The reason being is because when this scene first started he would find a lot of neat stuff in the Sonic Roms and not post it and two weeks later someone would post it and get all the credit. (For example, I know he found the Sonic 1 running special stage stars thingy long before anyone else) I just wanted him to get it out there. So if you want to be mad at someone for releasing it too early, blame me for that. I promise I won't bug him about anything until he has something really awesome to show like Sonic 2 in the GBA or something of the sort.

And also he put it out there now because he needed help with the engine. So if anyone knows how to fix the ... err wonky physics, please let him know.

 

ProSonic is a port.

And I think I'm aware of what significance this engine has in comparison to others, thanks. I question if you fully grasp the differences, however...

If he's doing a direct port as you say he is, then that problem should fix itself. If it was a clone, then I'd suggest doing some direct comparisons to how the original games handle to see the differences—that's the best way. I know saxman rigged up a program that takes keypresses and distributes them to two programs at once; something like that would be useful here, methinks, in order to compare performance.

I mean, in this particular case, it should be pretty obvious what the issues are—the animations don't update at the same rate, traction doesn't work correctly whilst rolling or running, momentum doesn't appear to increase correctly (I went down a long slope in Chemical Plant and didn't speed up one bit), among other things.

 

I did not know Pro Sonic was a port, I thought it was a clone. And yes I know the difference =P

That's cool, I should have these two get in contact with each other maybe. Again... my bad for thinking Pro Sonic was a clone, I should have had him wait on it >_<

 

I just hope you're willing to continue with developing this. That's really all I have to say right now.

I'll leave the butt kissing until I see it near finished. :P

 

I'll make sure of that

 

Don't worry if that does happen, dude. Focus on finishing and improving your project, take pride in it, even if there is better stuff out there.

 

I'm more excited about this than other Sonic-port/clones just because of the prospect of being able to use your work on the Genesis. It would make hacking so much easier. =)

 

I am curious. What would you guys like to get out of this? Would you like Sonic 2 ported to DS or GBA... or Playstation or something? I know I for one would love to see some kind of project where Sonic 1 - Sonic and Knuckles are all together in one game and playable on the DS. With this it IS possible (I think anyway, I think we figured out the size of the file would fit on the DS)

Also I didn't know that Retro Sonic used an actual Sonic engine. Last time I played it, it just seemed so so. I liked it, but I thought E02 and ProSonic were closer to the real engine.

 

I think a PSP port would be pretty good, myself. After all, it can run an emulated Sonic 2 at full speed, unlike the others.

 

I don't know where that came from, but none of the code in the Retro-Sonic engine is ported from the originals. It's all my own. In fact the 2008 revision of the engine is capable of more than just Sonic like E02, it's just that my primary use for it is for Sonic etc etc. I know the physics aren't 100% to the real games, but personally think that the difference is too minor to detract from it feeling like Sonic. I'm more focused on having a fast, flexible engine, with a good tool set (The RSDK) and nifty graphical effects... not to mention actually trying to get Retro-Sonic XG complete

 

Loops don't work!

To be honest, it plays and feels like it is some sort of OMG EARLY BETAZ or something like that. You know, when they're just throwing ideas down and just whipped up an engine to get an idea for what kind of gameplay they wanted and also to see how their art would look in motion.

At any rate, it seems to function just fine playing the included .exe using WINE.

Edit: well, it plays just fine, broken loops and sloppy physics aside. I mean it doesn't outright crash on me.

 

dammit, sorry. Stealth brought it up and I thought he meant it was a port. So ports are from Saxman and Stealth, right? Retro Sonic is a clone, right? Please tell me I got at least that right.

Did ANYONE read the first post? They're not SUPPOSED to work yet. They won't work until the objects are implemented which is the next step.

As for Sonic on the PSP, this idea intrigues me.

 

I'm still waiting to see if Retro Sonic will ever get out there to the public. Not only does it sound easier to use than the current programs(though I'll admit I can't be sure of that as I haven't researched them much), but the thought of Dreamcast compatibility makes it just all the more nifty :D

But to get on topic, I think this project shouldn't be discouraged just because of the numerous other engines. I think a 100% port of the genesis code to C could really help for porting to other platforms, and expand the possibility of Sonic games on more than just PC and Genesis(and DC is Retro Sonic ever goes public :p). If something like this were perfected then there could be more engines for all types of platforms out there.

Don't give it up

 

Well the loop programming relied on an external object to work. None are implemented in the build.

 

For those who don't understand this, there is a highly significant difference between emulation and a port. Emulation is the process of having one piece of hardware simulate other hardware in order to run a program that wasn't developed for the system, such as running a game developed specifically for the Genesis on the PSP. That responsibility falls primarily on the PSP's main processor, which now has to translate opcodes it doesn't natively understand, simulate a different addressing structure and process access to "RAM" and other hardware such as graphics and sound, and simulate the process that the Genesis hardware uses to turn that data into data that is THEN fed through the PSP's actual graphics/audio hardware. That's not to mention interaction and simultaneous operation of the Genesis's 68k and z80 processors. The video and audio hardware on the Genesis (and other game console systems) handle complicated processing of data, like generating the screen image from tiles, nametable tile maps, sprite mapping data, and sprite/plane prioritizing, which would otherwise put alot of stress on the main processor, and would render games like Sonic impossible with the Genesis' 7MHz processor. The PSP has a 333MHz processor, though, and probably still has a tile/sprite video mode that can still take care of blitting and priority (I'm not sure about that) once the data is converted to it's native format. All of the required processing would still be a tight squeeze, though, and isn't quite as easy to manage on systems with even slower main processors, such as the DS, which only has a 67MHz main processor (and although it also has a 33MHz subprocessor, splitting the task would just make things even more complicated, and that processor is already burdened with responsibility to manage some of the DS's hardware). I haven't used any DS emulators personally, but I imagine that it's pushing it trying to squeeze out a Genesis emulator to run games at full-speed. The more complicated the game, the more slowdown you're going to see

The alternative is a port, which would be written specifically for the system you plan to be running the software on. A port (created by a competent person, anyway) has the benefit of not having the overhead of simulated hardware, allowing it to run on "lower-end" systems, especially if that system still has similar I/O hardware (in that, in this case, it still has hardware tiled/sprite 2D graphics rendering, and optionally, some native FM synthesis or something, though if that were available, it would probably still have a different sound), which would be why Sonic 1 GBA runs so well. Similar ports of Sonic 2 and even Sonic 3 would run just as well on the GBA

One thing I have trouble explaining to people is that E02 is NOT a "Sonic Engine". I abandoned the program I used for "Project Mettrix" in 2003 for a rewrite, but I decided to make it much more extensible and generic. I've even started a Megaman game with it. I'm also still building "Project Mettrix" with it, but really anything that makes it "Sonic" is scripted, meaning everything that makes the character do whatever Sonic would, right down to the physics. Only the position adjustment and collision are handled by the program, and it functions differently than the original Sonic games in that it traces the path instead of jumping to position and checking for it again, which is much more "accurate", but is too slow to be reliable on something like the Genesis. I prefer the method for that project because it prevents falling off convex curves, or entering the wall when traveling around a concave curve too fast and stopping-dead, which shows up most prominently in Sonic 3

I'm not exactly sure I see the purpose. The current disassemblies are perfectly modifiable, and I'm not the only one who would disagree that translation to C would make it any easer. I'm aware that it's a common misconception people have that they would be better able to work with something if it were presented in C than in ASM even though they've never done anything in the way of game development in their life, but that's usually just ignorance and laziness talking; They don't know enough about either language to know that it takes just as much effort to learn and use either of them, which isn't to mention learning the basics of game development and how to manipulate their target platform, and so go for the easiest-sounding solution. I personally avoided ASM for a while, myself, because it seemed "scary", and I still don't like x86 ASM (not only because it's kind of crappy, but also because of the rest of PC architecture, including Windows), but I instantly felt at ease using 68k ASM once I gave it a chance. Also, the C edition would add overhead during compilation through code that isn't quite as optimized, unnecessary header/footer code in function calls during compilation, etc.. , not to mention any that may be intrudoced during the translation process itself, which overall causes the program not to perform as well as the original in that it will be larger, extra processor cycles would be used by many operations, and there may even be wasted RAM depending on how RAM usage is set up. Working with a higher-level language like that unnecessarily forfeits a significant level of control over the generated code

That's to say nothing about portability, I just disagree that a Genesis C rewrite is especially practical. In terms of portability, though, you will have concerns about data formatting in terms of making use of the system's hardware, such as the conversions I had to do for the GBA, as it wouldn't be appropriate to leave conversion up to the program during runtime (it has to be done at some point). I don't think that was really made clear. Also, if Genesis "backward-portability" were taken out of the equation, there's alot more room to change how things work, which I mention in reference to what your original, unmodified post said about expansion. That's when you get into the prospect of keeping something like the physics entirely pure, or going the route I did when I decided how to manage level collision with E02, where the whole "exact port" thing kinda starts to fall apart.. It really depends on what you or any of the users actually wants to do with it, I guess

 

Well, I know it's something Rob's wanted to do for a long time and even though you don't find ASM all that hard, I know other people prefer C. It's all French to me either way but...

I understand that you have doubts and are warning him about certain things, but Rob knows what he's up against. He's dedicated a lot of his time to this, and hey as far as I'm concerned, if he wants to do it, he should... Wouldn't it be awesome to have all of Sonic 2 on the GBA? Remember how much people loved your Sonic 1 on the GBA?... imagine the whole game. Rob's just making it possible and he's programmed for the GBA before so I'm going to assume he knows what he's doing in that aspect. In the long run I think it would do more good than harm.


Also I'm not trying to argue with you or anything or start anything, you do bring up a lot of good points. I'm just one of those "Hey if you wanna do it, go for it" people.

 

Well, I was responding directly to the "backward-portable" comment when I said that, with my reasoning explained in the following sentences. That's the bulk of my issue with the whole "C" factor, as, yeah, it makes a whole lot more sense to stick with the ASM as far as the Genesis goes (and I would extend that to other systems within roughly the same generation or earlier), but there are a lot of people that don't realize that, and the ones who don't understand why probably wouldn't have any luck doing very much of anything with a Sonic game in any language

You also bring up another point I forgot to mention. A full release like that is treading on dangerous territory. Precident for distributing sourcecodes like the current disassemblies is set by court cases legalizing obtaining method by means of reverse-engineering, and PC game source releases such as Wolfenstein, DooM, Half-Life, I think, and probably others, which provide you with the code, but no more data than you were given with the shareware version. That's where this becomes an issue, releasing the code (or a derivation thereof), along with all original data is hardly any different than distributing copies of the original build. It's copyright infringement/piracy. I was under the impression that that's why the data for the disassemblies was set up to be extracted by the user instead of included with the package, but I guess the decision may have been based on download size concerns (even though that then makes it slightly more difficult for the user to set up). This is why I didn't create a complete Sonic 1 remake when I made the original GHZ test level for Project Mettrix, and why I didn't create a full-game port to GBA myself. That's not to mention that it would also render me unable to use the prospect of a complete port as an incentive to get any professional work, or could cause the company to take and distribute my work for their own profit, but those things are beside the initial point I was making. This was what stood out the most to me when I saw that a significant portion of the game data was included with the current demo, and that seems to be the part of the product held most important to a company

I wasn't really telling him to stop doing anything, but those are some things I thought were worth mentioning

I also wonder, though, why the current demo has the errors that it does when Rob mentioned "recreating the game engine code instruction by instruction". I understand that it's incomplete; I'm just confused about why it performs incorrectly in EXACTLY the way that it does..

 

Hmmm I guess I don't know enough about copyrights to answer that part... as for why it performs the way it does... Rob will have to answer that for you tomorrow.