Stealth, on Dec 1 2008, 01:59 AM, said:
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.
This is truly a "to each his own" type of argument. I can work with assembler just the same as I could clean oil out of cement floors for a living. I've done both but prefer neither, if I have a choice. This provides a choice. I find assembler something I can handle, but it requires a lot more brain power and imagination, and it's all too easy to screw up the stack or modify the wrong register and get unpredictable results, which was one of the problems I constantly ran into. And on your next point...
Quote
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
This is true. However, of all higher level languages I could use, I know of no greater controllable language than C. The memory you allocate is very specific based on types you use. I have so far recreated all of the major arrays used by the system and require exactly the same amount of memory they originally took, I ensured that with tests before committing. If you use GCC cross-compiling for 68K the RAM will be the same. Yes, there is always the trouble of the code not being as efficient. This is a fact of life with any higher level language. The best thing I can say is, observe the same healthy practices you use in assembler in C. Don't make unnecessary function calls (inlines are supported even in C with GCC), perform shifts / logical operations as appropriate, avoid straight up multiplication and division as much as possible. And, of course, turn on optimizations. I also do post-compile audits of code to see if they've become "ridiculous." However, GCC has time and again shown me some amazing generation that I personally would never have thought of doing if doing assembler by hand. Obviously that's not ALWAYS the case, so mind critical loops. It's a programming game. If I get further along and see that the performance will never be adequate (it will almost certainly be less, but I wouldn't write it off yet) then I'll see the futility of it.
Quote
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.
Good ol' endianness.
Right now there are #if/#else preprocessor blocks that change endian-specific accesses, and I leave big endian as the "main" format so that Genesis is doing zero conversions yet the PC is doing a few minor load-time-only conversions. And technically my "resource packer" in use on the Genesis is also setup to later post-convert resources automatically for a little-endian based ROM system (I.e. GBA) since it ties into the loader code and thus will pre-convert resources as necessary.
Quote
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
Yes, that will depend on that. My first goal is to make it work. But keep it abstracted enough that the graphics system can be pulled later and replaced with something better.
Stealth, on Dec 1 2008, 02:48 AM, said:
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
Well, first of all, the "final" version of this, since it uses the same data in the same format as Sonic 2, can and likely will be distributed without data. I only did it this time for a quick "get up and go" demo. We didn't get into how my system works in detail. The "resource packer" program gathers up resources into a ".s" file and produces a header file that gets compiled with GNU as and externalizes labels. This is linked with compiled source. Thus there is no reliance on data actually being present in your code. So there's no reason I should have to distribute it either. (Just source and the freeware compiler.) And because I put the main code in a library and game specific code outside of it, making a whole new game is as easy as throwing away the other half.
Believe me, I did consider that venue. However, I have no evidence to support this, but I have heard from two different people with completely different associations that say that Sega has "lost" their original source and they actually are interested in what goes on with these works, rather than against them. I don't know if that's true, but I can see the possibility in the situation. Obviously if I got a cease and desist notice I would quit. But yes, the future would be a source/binary distribution sans data, and someone will have to use the existing tools on their own ROM with the split and whatnot OR obviously use their own data and forgo some of that legality. I don't know what can be said other than there's probably no practical difference to distributing assembler and data versus distributing C and data. All of us being in this association are treading foreign waters and that's just the name of the game.
As for your hope of professional work, I have no comment. Maybe it will happen, maybe it won't. I would say there's a far greater chance they're waiting for one of me so they can get it free than waiting to pay you. They are likely more interested in developing based on resources available to them, especially with some abysmal Sonic titles ruining the name and putting them in deep water. Sure I would love to do it for the same reasons you have, waiting for a paycheck for a hard earned porting job, but I'm not holding my breath. I'd rather do it and talk about having experience working with 68K assembler and making C ports of functions (non-specifically) than waiting for a contract that may never come. (Although seriously, if you're contracted tomorrow, I'd probably quit out of respect.)
Quote
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..
Okay, I "sales pitched" that a little bit. It is instruction by instruction, but my guess is I made a few misinterpretations, based on the problems I do have reading assembly. It's darn close with subtle errors. I've gone through it before casually and found conditionals that get reversed or forgetting to pay attention to byte access and thus not wrapping an addition value in C correctly (which likes to convert up to integers if you're not explicit.) It just means it's time to audit the source function-by-function and clean up errors. Which I will certainly do.
This post has been edited by Rob Jinnai: 01 December 2008 - 07:56 PM
roxahris 
00
