Everything you are describing is a function of the vdp or ppu which are handled independently of the cpu.
Actually the ppu can handle more sprites at once than the vdp.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Could have Sonic the Hedgehog been done on the SNES?
- Thread starter CurseoftheGods
- Start date
- Status
Everything you are describing is a function of the vdp or ppu which are handled independently of the cpu.
Actually the ppu can handle more sprites at once than the vdp.
Character animations in old consoles are handheld independently of the CPU since win?
If its not processing on screen effects, animations and transitions, then what does the CPU even do? From what you are saying, the CPU did nothing.
Since the advent of the vdp. Animation is changing references to tile pointers which are handled in vblank, done by the vdp using dma. If course the video display processor handled animation, that's it's purpose.
I go into pretty in depth detail about the role of the cpu itt. But to be succinct, the role of the cpu is math calculation, input polling, and memory allocation.
And here I thought the video display processor's primary purpose was displaying video.
Still sounds like the CPU is useless with the way you are detaching it from involvement with all other facets. Like it has absolutely no involvement in anything you see occur on screen.
Well, you thought wrong. The VDP handles all video processing, including interrupt counting, tile collision detection, scrolling, independent DMA, etc. All of which it has actual circuitry to do. The VDP is what directly accesses and writes to VRAM.
Here you go, a primer on Sega Genesis VDP programming: http://cgfm2.emuviews.com/txt/genvdp.txt
Well, if you think math is useless... k.
Calculators are very useful, but that clearly isn't what I'm talking about.
I'm talking about the impact of the CPU on playing a game on the Sega Genesis. Your statements assert the CPU as doing next to nothing as far a playing the game goes.
But you are attributing functions of the VDP to the CPU.
And, to be kind, I don't think you understand what I'm saying.
BennyBlanco
aka IMurRIVAL69
Could Genesis have run Stunt Race FX?
With the SVP, sure. In pure software... probably not.
Hence my questions, because what you are saying makes little since to me.
Your statement's point to the CPU having absolutely no involvement in frame rates, character movements or anything that happens on screen. Like its not even necessary and is just there for arbitrary mathematical calculations. That is what your statements as you presented them seem to amount to.
Virtua Racing did use a fancy chip. It is the only Genesis game to use it to my knowledge. I posted a list of 3D games earlier in the thread. Or that may have been another thread.
There are quite a lot of Sega Genesis games that use polygons and have no special chip.
https://www.youtube.com/watch?v=1pt2CIjFRwU
https://www.youtube.com/watch?v=CyLy_x6dY44
Correct, the VDP is an entirely separate processor to handle all that stuff outside of the CPU entirely.
You should click the link he posted. He didn't submit Virtua Racing.
BennyBlanco
aka IMurRIVAL69
That first one is really impressive if it's not being emulated. Stunt Race FX ran at a horrible framerate.
Kind of makes me sad that we'll probably never see goofy shit like an on cartridge co-processor again.
Then I ask again, What purpose does the CPU serve towards playing games functionally? If all of the movements and animation are handheld with no involvement from the CPU, it sounds like you could remove the CPU from the console and it would not make much difference.
it's running on actual hardware!
The SVP has a hard limit of 15 FPS, pretty much in-line with what the SFX would produce.
Kinect 1 almost included a DSP to handle its calculations. They cheaped out at the last minute and offloaded its work onto the Xbox 360 CPU.
They probably could have got it running on SNES, but I assume it would be heavily compromised due to that CPU.
try all the game logic. Game physics. as well as software rendering techniques, and any and all math calculations.
He's saying that animations, scrolling and h/vblank and detecting overlapping sprites are managed by the vdp. the cpu still does a load of work.
Yes, I read that the first time. It doesn't answer my question though. What does it do "functionality". As in real world effect on "gameplay".
Honestly, the CPU sounds like a waste of money as you are describining. It makes no sense to use such a relatively fast CPU(for the time) for nothing more than basic math and basic memory allocation. I would expect things like that to be primarily handled by coprocessors, not the main CPU.
The big things here is the CPU vs the one in the SNES. I've observed most Genesis games running faster and fluid, usually twice as much, on the Genesis than the SNES and have always heard this attributed to the faster CPU. Now you are saying that it has nothing do with the CPU which doesn't add up.
I'm familiar with the basic functionality of CPU... My issue here is the assertion of complete non-inolvment in the performance on screen by the CPU which goes against what I've heard from all other sources. What I garner from what he is saying is that the CPU has nothing to do with games from faster and more fluidly on the Genesis than the SNES.
With do respect, it sounds more like you don't understand the answer.
You expect an external processor to handle memory allocation? How would they even communicate, you talk to coprocessors by setting registers - which is memory allocation.
Nearly every game on the SNES or Genesis runs at 60 fps. This is because calculations are done in vblank and hblank, so strict timing is necessary.
That's exactly what I'm saying. I'll go one step further, in fact: Genesis games are not "more fluid" than SNES games.
I really don't think so. You don't seem to understand the role or purpose of a CPU, or how a program is executed.
You are correct. That is why I am asking for a more tangible explanation.
My mistake with the memory allocation. I was thinking RAM in the genesis could communicate with the graphics processor for loading graphical data in and out directly without the CPU's involvement.
Though, I was referring to the on screen fluidity, like in the videos I posted, not basic frame rate.
I've been programing for 8 years and have made 2D games.
On retro hardware, though?
No. That is why I am asking about them. All I know about retro hardware is what I have heard from others and have read. What I am hearing from him isn't entirely matching up with what I've learned elsewhere.
The basic summation, from what I understood, is that for the Genesis/Megadrive: Faster processor = faster game and SNES: More colors and higher resolution which are differences I have personally observed in many crossplatform ports. Now he is telling me this has nothing to do with the CPU which raises the question, "what is the significance of the CPU in the Genesis being twice as fast as the one in the SNES then? What functional difference does it make as far a gameplay goes.
I... I can't believe this is still a thing.
Blast processing was a marketing gimmick. Both systems were capable of running a game so fast you couldn't see anything that was going on. SNES had several examples of games running at speeds like Sonic did.
I thought we all knew this now.
Blast processing was a marketing gimmick. Both systems were capable of running a game so fast you couldn't see anything that was going on. SNES had several examples of games running at speeds like Sonic did.
I thought we all knew this now.
entremet
Member
I wonder how many people are aware of Sonic 1 Japan's better graphical effects?
The game was released later in the Japanese market giving the developers more time work on it. You got some nice effects, like the underwater one in water stages and some others.
I mean, at least read the thread, my friend.
The game was released later in the Japanese market giving the developers more time work on it. You got some nice effects, like the underwater one in water stages and some others.
I mean, at least read the thread, my friend.
no. Blast processing while a PR term did refer to actual hardware, as already states several times in this thread.
The best examples mentioned earlier in the thread were that the faster CPU allows for higher quality physics and stronger decompression routines, both of which take a ton of simple math to execute and have everything to do with the ability to pull off something like the Sonic games.
I see. Physics and compression are certainly not things i think about when I think older hardware. Though, that is a better explanation.
What I'm looking for is an example of these. Like a specific ingame example of something that was or could be done in a game on the Sega Genesis "because of the CPU" that could not be done on the SNES to the same extent.
So let's examine a basic hack to understand the role of the CPU: Adding a spindash to Sonic 1.
First up, Sonic's list of attributes are stored as Obj01, which is defined in line 23466. When the program is executed, it will jump to a subroutine for this object which will allocate memory for all his local object variables, velocity, speed, angle, etc. The CPU itself will set the registers and RAM locations to store these variables for the Sonic object upon object creation.
In the location Obj01_MdNormal are a bunch of conditional branches to handle Sonic's actions in different situations. These are bsr branches - branch to subroutine. Essentially, the CPU takes two values stored in two different registers, compares them, and if they are equal, it sets a flag in a result register that gets looked at to determine which branch the subroutine should take. In our example, we want to add a conditional for when Sonic is ducking and pressing jump, like so:
Obj01_MdNormal: ; XREF: Obj01_Modes
bsr.w Sonic_SpinDash ; This is the line I'm adding in this spin dash example
bsr.w Sonic_Jump
bsr.w Sonic_SlopeResist
bsr.w Sonic_Move
bsr.w Sonic_Roll
bsr.w Sonic_LevelBound
jsr SpeedToPos
bsr.w Sonic_AnglePos
bsr.w Sonic_SlopeRepel
rts
The top bsr will take us to the Sonic_SpinDash subroutine provided the conditional is met. Now here is our Sonic_SpinDash subroutine, I'm just going to describe what the CPU is doing in comments after each line:
Sonic_SpinDash:
tst.b $39(a0) // test a conditional if pointer at address 0 holds a value equal to $39 (testing to see if spindash flag is set), sets z flag if condition is true
bne.s loc_1AC8E //if z flag indicates previous condition is false (because we're using Branch Not Equal) branch to location 1AC8E (i.e. bail on the subroutine)
cmpi.b #8,$1C(a0) //compare integer "8" to address 0 ('8' is a bitmask for controller input at this point), sets z flag if condition is true
bne.s locret_1AC8C //if z flag indicates previous condition is false (because we're using Branch Not Equal) branch to location 1AC8C (i.e. bail on the subroutine)
move.b ($FFFFF603).w,d0 //move word value "FFFFF603" to data register 0 (this is the value of one spindash "revolution" to potential velocity.
and so forth. I don't really have the time to go over each individual line in this hack because I'm at work, but you can see what the CPU is doing very clearly. It's comparing conditionals, allocating memory, doing mathematical computation, polling for input... the things I described.
any 3d done on the megadrive will be software rendered on the cpu with the cpu writing to pixels directly.
Of course. That why posted those 2 videos above of the 3D games running on the stock genesis hardware.
I was speaking more in normal 2D game terms. If I am seeing this correctly. The CPU should be what is responsible for all sprite positioning on screen, correct? This would mean that the CPU would be able to calculate far more changes to position on the Genesis CPU per second than with no performance drop than it would on the SNES. By this token, it would allow the game to appear faster. That is my understanding of it.
Now that makes a lot more since to me. I always wondered why Sonic 3 looked so different.
That sounds like the CPU is the backbone of everything, including the animations(since it is responsible for loading the objects in memory, then you would have nothing for the VDP to draw if the CPU was not loading the objects to memory fast enough).
you flat-out don't understand how these machines generate their visuals. Execution is done in order, top to bottom, line by line in the binary. You can split execution into two phases - Hblank and Vblank. Hblank is when the gun on the raster is actually drawing to the screen - the VDP is engaged telling the raster what to draw on screen during these segments, and when the raster is being reset, you get a brief moment of inactivity where the CPU can kick back on to do several small calculations. In the Sega Genesis, these calculations are typically small mathematical calculations storing their values in registers because the Genesis has so many registers at its disposal. These calculations get done during these hblanks but sit unused until vblank - the moment when the raster gun resets back to the top of the screen. 1 vblank is much longer than 1 hblank. So, during vblank, the VDP uses DMA to move all the calculations from register into vram so that it can act upon these changes. With these calculations in vram, it can now scroll the background, move the sprites, detect collision and throw flags, etc. All this is done at once in vblank to prepare for the next frame. While the VDP is doing this, the CPU is free to act completely independently of these operations, which is does for other types of CPU functions (input polling, more math calculations, memory allocation, etc).
These machines don't work like you think they work, their ability to update the screen is fixed at a regular interval that is completely independent of the CPU speed. The CPU does not "update the sprite position" and then it immediately gets reflected upon the screen. The speedier CPU means nothing to "fludity." The VDP takes all work essentially stored in cache at once during vblank.
The PPU works in the same way.
Objects aren't animation routines, they are objects. Animation routines and tiles are stored in vram which is handled by the VDP. And how fast the CPU can "load objects" doesn't come into play.
That's disappointing then.
I also recall seeing that the Genesis had direct memory access or something of that like, while the SNES didn't and that it affected how well games ran.
I'm guessing that just a Java feature. I'm used to declaring animations routines as objects.
It's not disappointing, machines that directly tie how fast it can process visuals to how much load the CPU is under perform terribly. That's how the Atari Jaguar worked and it's why Alien Vs Predator runs at 60 fps with no controller polling, no enemies, and no sound effects, but 15 FPS with all that included. Divorcing your graphics from your CPU is a good thing.
I directly reference Direct Memory Access many times in the post you just quoted. You can think of DMA as sort of working like a blitter - it copies and access memory extremely quickly between locations.
Honestly, I'm repeating myself here a lot, you should read the whole topic.
Son of Zardoz
Neo Member
Krejlooc--thanks for all of the incredible information in this thread. I vaguely knew the differences between the Genesis & SNES but the detail you've provided in this thread is fantastic. Really sheds a new light on how differently the systems worked.
I had a Genesis back then and loved it--it's still probably my favorite system of all time but I did get to play a healthy amount of SNES at my neighbors house.
I had a Genesis back then and loved it--it's still probably my favorite system of all time but I did get to play a healthy amount of SNES at my neighbors house.
The only way to really put a dent in all the myths and misinformation that keeps getting brought up in these kinds of discussions is to have a YouTube video with a snazzy presentation neatly explaining all of this in layman's terms, and then having it go viral.
I know what DMA is.
I was referring to the presence vs lack of DMA as they relate the Genesis and SNES respectably and how faster the performance is. I read that it allowed the Genesis to perform tasks much faster than the SNES and that it is also what SEGA was talking about when it used the phrase, blast processing, as opposed to just the CPU being faster. I wanted to verify this, as it seems that I've come across a lot of misinformation on this subject.
Thing is, this isn't layman stuff. This is nitty gritty about how the hardware worked. It's all cumulative knowledge - you have to know the stuff before to understand the stuff ahead. I find it really hard to just dive into a technical discussion because you can never be sure of what the other person understands. You could spend years explaining this stuff because it's actual computer science.
It's even harder when you account that people who are familiar with how modern systems work have a conceptual understanding of hardware that runs completely counter to how these systems worked. In that case, knowing too much is sort of like knowing things in reverse.
Just keep in mind that hardware still works like this - there are tradeoffs in everything. People like to boil down things to linear comparisons (X is better than Y which is better than Z) but when you are talking about computing, a lot of times hardware isn't really wholly better but rather just different. Like, hardware 1 might be good at ABC and bad at XYZ, but hardware 2 might be good at XZY and bad at ABC. Which one is "better" depends on what you want and need to do.
Just keep this in mind when people argue about technology using DBZ power levels.
Hero of Legend
Member
Hey Krejlooc, have you ever been at a game company? You sure know a lot about how systems work inside, just curious if you ever made/worked on games yourself. 
The point is that the general perception people seem to have about this is that the faster CPU only accounts for stuff like faster scrolling (which most consoles of the time can pull off without much trouble, like they talk about in that AVGN video about Bio Force Ape), les slowdown and more sprites on the screen. You see this sentiment repeated over and over again in the thread by people who don't take the time to read through all the information available here.
The message that needs to be sent is just how many general applications it has that makes so many things more feasible, with great practical examples being the physics of Sonic or compression enabling better/more varied visuals and just generally more content on the same cart size.
Baron Aloha
A Shining Example
In the SNES version of Bubsy there were times in that game where you would enter a warp point and come out on the other end of a level and when it did this it would actually scroll the level really fast to that point... much faster than any Sonic game... and without any slowdown.
Based on that I'm going to say it could have been done.
Based on that I'm going to say it could have been done.
You are a very patient man...
This thread WAS a real pleasure to read, thanks to your very interesting insight, but it seems that some would just like to pester and challenge the best posters.
In anycase, I think Krizzx thinks that everything that is displayed, or moved on the screen, is now what is handled vpd, and can't understand that it takes "processing" to run a game, outside of simple sprite manipulation.
Oh well... I guess because we now have GPU's in our computers we don't need CPUs anymore too, well seeing as everything that we do is put on the screen and all, and that's what GPU's handle, the video output right?
- Status