- Member: Members
- Active Posts:
- 654 (0.18 per day)
- Most Active In:
- General Sonic Discussion (243 posts)
- 17-June 07
- Profile Views:
- Last Active:
- Yesterday, 09:01 PM
- 35 years old
- March 14, 1982
- Rio de Janeiro
- Platformer for the NES
- National Flag:
Topics I've Started
05 October 2015 - 11:08 PMHey! It's been a while since I used my actual Genesis/MD cartridges (it's either emulators or Everdrive these days, but even those are rare, to be honest), so I haven't thought about this in a while, but today I remembered that my original Sonic 3 cartridge was never able to save games. I got it new, when the game first came out, and as a kid I never understood the existence of all those save slots, along with a "no save" option, since turning the console off would always wipe everything away. Years later, after reading about the game online, I realized that the game was indeed supposed to save, and then I was sure there was something wrong with my cartridge. I forgot about that for years again, and only today I decided to look at the PCB and see if there was anything visibly wrong with it:
Turns out there is something wrong: a trace appears to have been intentionally cut on the back of the PCB (indicated by the red arrow). Looking at pictures of another cartridge that doesn't have capacitors blocking the view, it appears that this trace is connected to pin B28, which an online search reveals to be labeled LDSW (even words of SRAM). I'm not very familiar with SEGA hardware, but that name does sound suspiciously related to saving. It's hard to follow where the trace goes after the cut, but it does look like it could go to the FRAM.
Is anyone here familiar enough with SEGA hardware to confirm that this is why my cartridge was never able to save games? Why do you think TecToy (I live in Brazil) would cut this trace on purpose? Are there other brazilian carts known to have this problem? That doesn't make any sense to me. I'm not sure I should try fixing that connection, because there must be a reason for it having been cut in the first place.
EDIT: Crap, somehow this ended up in the wrong forum section. Mods, please move it to the appropriate location. Sorry about that.
02 February 2010 - 07:52 AMHey everyone. As some of you might remember, I've been working on a Sonic game for the NES (for a long time now, but it's hard to find the time to do it). So, with a decent scrolling/rendering engine capable of displaying large level maps working, it's time to think about programming the Sonic object.
We all know that what makes a Sonic game deserve that title is the physics, not the blue sprite, so I want to code a character that's as fun to control as his MD/GEN counterpart, but the problem is that I don't have the same CPU power as the original games. I don't think this is a reason to be extremely worried about, because the Master System games for example had very different physics but were still enjoyable in their own way (it wasn't frustrating that Sonic didn't move exactly like he did on the 16-bit games, at least not for me).
Recently I've been reading the Sonic Physics Guide, to know the basics about how the 16-bit games work. I found that many of the solutions I had thought of were similar to what was presented in that guide, but there are several details that are hard to figure out without deeper investigation, such as when each type of force is or isn't applied, the exact values of those forces and things like that, so it was a very interesting read.
So after looking at the original physics, my conclusion is that the constant multiplications needed to convert the speed into horizontal and vertical components (and everything else that deals with sines and cosines) are probably the the most CPU-intensive parts. I don't remember if the 68000 has built-in multiplication, but the 6502 (the NES CPU) certainly doesn't, so I'd like to keep multiplications to a minimum.
Anyway, the reason for this thread is asking you guys what kinds of simplifications you think could be done in order to reduce the CPU load while processing the Sonic object, without sacrificing the fun. If anyone knows a bit about how the SMS games work as opposed to the 16-bit ones and wants to share, that would be great. I don't want to copy the 8-bit games exactly though, because I want to do things they don't, like making jumps perpendicular to the floor.
I think I'm going to use the quadrant thing, where different modes (floor, right wall, ceiling, left wall) are used to keep Sonic attached to the "ground" depending on his angle. I'm thinking about not converting the ground speed into horizontal and vertical components though, and just using it directly as fully horizontal or fully vertical, depending on his angle, while the other coordinate just follows the ground. Maybe with careful calibration of the resistance of the slopes it will not feel so different. About the perpendicular jumps, that can possibly be done using look-up tables for each possible angle, since the initial force for the jump should be constant.
If you have any interesting ideas, let me know. Also, if you foresee any problems that these simplifications might generate, that will be nice to read too. Thanks in advance for any suggestions!
19 January 2008 - 05:28 PMHello guys! Because of the limited number of trial posts, I'll first give you a short description of my current project, and then I'll ask the actual question, OK?
I'm a big Sonic fan since the first game came out (not such a big fan of the newest ones, though), and 'till this day the Mega Drive/Genesis Sonic games are still my all time favorites. Since I started programming, my dream was to code a decent Sonic game from scratch.
Since I'm a big fan of the NES, I learned how to program for it a few years back. I happen to really like the idea of pushing the system to it's limits, so I just decided to code my sonic game for the NES. I wanted to do better than the pirates that exist for the NES (Somari and Jurassic Boy), because those are pure crap (the physics, more than anything). I also wanted to do better than what was done for the SMS/GG, which are nice but have a few problems, such less-than-smooth movement, repetitive graphics, small levels... I wanted the opposite of all that, becuse I really believe we can achieve more with 8-bit hardware. So the goal is to go beyond all other 8-bit games, getting as close to the 16-bit series as much as possible.
Everything is comming along pretty nicely: The scrolling engine works perfectly (it's able to scroll 16 pixels per frame in either direction, both if necessary), in levels that can be really large (built with 256x256-pixel "blocks" - like in Sonic 1 - each indexed by a byte in a level map of up to 1024 or 2048 bytes, depending on how much RAM I have left in the end), larger than anything I've seen on the NES. The sprite engine works well too (although I feel it could be optimized a bit). Anyway, there is still a lot of free processor time that will be used to process the active objects, as well as Sonic (or another character I'm not revealing yet), and I suppose that will be the most intensive task to perform, so the rest of the engine must be very efficient.
I often come here and read about all the things you guys have discovered about the original engines, and I usually try to have the things in my game work in a simiolar fashion, as much as the hardware constraints permit. It's not unnusual having to rething something so that it behaves the same but is implemented in a way that requires less resources.
I hardly go look at the disassembly of the games directly, because I don't want to copy that much. Plus, I'm not fluent in 68000 assembly (as I am with 6502 which is what the NES uses), but even when I'm able to follow the program flow with the aid of some documentation, there are a lot of details about the engine (and the Mega Drive hardware) that prevent me from fully understand the logic.
Here's the actual question:
Thing is that I haven't found much info about how the original engine goes about loading the objects
and this is the first real problem I'm facing. I have thought about a few different solutions, and although all of them could've worked, they all seem to have flaws. One of them is too slow, another one imposes limitation on object placement, another needs too much RAM, and so on.
What I'd like to know is if you guy could give me a description of how the main game engine finds in the object definitions the objects that are in range and should be loaded. By looking at Sonic 1's disassembly, I can see that this is done by the "ObjectsLoad" routine, but I'm having a hard time figuring out what it does with the object definitions.
I'm aware the the solution used by sonic Team may not apply to my engine or to the system I'm programming, but I'm running out of ideas here, and before I decide to go on with an sub-optimal design, I decided I'd ask you guys about it.
Thank you very much for the help!
tokumaru hasn't added any friends yet.