Decreased S-CPU Velocity: Real or Imagined?

[TOUKO]

This is not a question of who's better, stef cannot accept than some impressive games exist for snes or PCE because all two have a 8 bits CPU ..
I saw some shmups on PCe/snes that are at least, as impressive as TF3/4 or Gh in term of cpu usage and sprites on screen .

[Drew Sebastino]

two have a 8 bits CPU ..

You mean 1, right?

I saw some shmups on PCe/snes that are at less, as impressive as TF3/4 or Gh in term of cpu usage and sprites on screen .

If I recall correctly, one of the TF games on the Genesis actually has some slowdown. (Not Gradius III level, but definatelly not far away enough to brag.) Anyway, I said that Space Megaforce looked as good as Gunstar Heroes in that there are the same amount of sprites and stuff flying around, (and other CPU taxing stuff,) but he complained that it didn't have enough animation and that the game seemed "stiff" because of it. They're spaceships, they don't have arms and limbs. All you need to do is create multiple frames of the ships at different angles, which the game does.

also TOUKO, I think you mean "at least", not at less. I completely changes the meaning of the sentence.

[psycopathicteen]

A lot of big name companies used very traditional methods, and were afraid to deviate from the standard.

[tokumaru]

And programmers didn't necessarily have a lot of experience with the systems or CPUs they were using, which explains that kind of conservative programming.

Being a good programmer allows you to code for practically anything if you have proper documentation, but that doesn't mean you'll become a master at it overnight.

[Drew Sebastino]

Are you referring to animation, psychopathicteen? Most of the "clever" ideas I thought of (like the sprite vram slot thing, even though you actually mode the idea into code. I'm going to do this, but I've been a bit busy.) I thought were standard. I looked at the DKC games in the bsnes games in a debugger and assumed that all games were as solid from a technical standpoint as they were. I looked at other games and saw how they did stupid stuff like store all the palettes for every enemy in the entire game in cgram, even though there is only one type of enemy on screen at a time and others. I had thought that DKC did the same thing that I thought of with finding vram for sprites, but it appears that Rare's way was actually simpler.

New post just came in while I was typing:

Being a good programmer allows you to code for practically anything if you have proper documentation, but that doesn't mean you'll become a master at it overnight.

I've learned that with x86.

[Sik]

If I recall correctly, one of the TF games on the Genesis actually has some slowdown.

I thought all of them did o.o (although I believe TF4 slows down right in the first level around the area with the large snake-like enemy) Also reminder that they can't play PCM while anything else is playing either (even TF4, which is from 1992 and was unexcusable by then).

And programmers didn't necessarily have a lot of experience with the systems or CPUs they were using, which explains that kind of conservative programming.

Deadlines usually play a much bigger role (forcing programmers to just stick to something quick that works than bothering to come up with good code).

[Drew Sebastino]

I thought all of them did o.o

They probably do, I just never played them.

[psycopathicteen]

I was referring to game physics. Konami/Treasure relied heavily on 16.16 physics which is convenient for the 68000, but not for the 65816. On the 65816 it's better to do physics in a signed 8.8 format with the coordinates being in 16.8 format.

[Drew Sebastino]

I'm not even going to lie, but I don't have the slightest clue what "16.16" means. Is it just the first 16 represents pixels, and the second 16 is subpixels, like to where when you made metasprites, you only dump the first 16 bits? I guess this would be convenient for the 68000, because it can do some 32bit instructions. Really though, this doesn't seem hard to fix. Physics for y would only need to be 8.8, because 256 pixels is large enough to cover the height of the screen and hide 32 pixel tall sprites.

[tokumaru]

Physics for y would only need to be 8.8, because 256 pixels is large enough to cover the height of the screen and hide 32 pixel tall sprites.

Ideally, physics happens in level space, not screen space.

[Sik]

Yeah, level space would make 8.8 pointless.

What I do these days with the 68000 though is store coordinates as 16-bit integers and speed as 8.8 fixed point, and then make use of subpixel faking to work around that. Kind of lame, but saves memory, makes things simpler (by being able to ignore subpixels almost everywhere) and should be easily doable on either system really. Heck, on 3rd generation systems this should be easily feasible.

Amusingly, Miniplanets uses 8-bit coordinates (!!). This was to make looping maps easier, I just abuse overflow =P

[TOUKO]

also TOUKO, I think you mean "at least", not at less. I completely changes the meaning of the sentence.

Oups yes

You mean 1, right?

The 65816 is a 8 bit datas bus cpu, for me it can not be a true 16 bits like the 68k can not be a 32 bits .

A game is not related only to physics, physic is used in few games and i don't think it was applied for all sprites .
you must count all branch/tests, variables read/write, subroutine calls, interruptions,all this stuffs which are far slower on 68k ..
For my PCE stuffs, i never used any 32 bits operations, on a 2D system i think is useless,or at least is not really an advantage .

[Drew Sebastino]

What I do these days with the 68000 though is store coordinates as 16-bit integers and speed as 8.8 fixed point, and then make use of subpixel faking to work around that.

That's a good idea! It really isn't any different than 16.16 fixed point, because sub pixel coordinates don't really help collision detection and things, but they do help velocity. It actually seems more like an optimization than a compromise, and is obviously useful on the 68000 (as 32 bit instructions are supposed to be slower). Well, that's one area an SNES version of Gunstar Heroes could be faster in (Because Treasure was supposedly using 32.32 fixed point, even though it was unnecessary).

I completely changes the meaning of the sentence.

Dat grammar. I meant to say "it". (You're not the only one who has trouble writing, TOUKO...)

[Stef]

What I do these days with the 68000 though is store coordinates as 16-bit integers and speed as 8.8 fixed point

How do you actually add the 16 bits integer coordinate to the 8.8 speed efficiently with the 68k ? You probably waste some cycles using that no ? the 16.16 is very practical, using 32 bits only for the speed addition and 16 bits when sending position in vram or for collision calculation.

[Drew Sebastino]

Well how do you change accumulator (or whatever here) width on the 68000? On the 65816, It only takes about 1 or 2 instructions, and I'm pretty sure the instructions only take 2 cycles, which is the smallest amount of cycles any of the instructions have. This wouldn't be the first time different approaches are better for different processors.