Multijointed Monster Maker

My sources contradict eachother, and I'm left confused. Anybody knows for sure what happens? a) graphical glitches b) dma halts till next v-blank c) dma halts till next h-blank d) dma goes slower than normal e) dma is ignored and nothing happens

I heard Bsnes is the most cycle accurate. I always wondered what happens when you dma during active screen. Some sources say it puts garbage onscreen, while other sources say it waits till the next v-blank. What is the correct information? If it waits till the next screen, then it directly causes slowdown, if it puts garbage onscreen, then programmers would have to program something to keep track of cycles and force the game to slowdown. My engine doesn't turn the screen on until all dma-ing is finsihed, so if there is too much data that has to be updated, there will be a little flickering at the top of the screen. V-blank is the only part of programming where I worry about counting cycles.

I'm making a run-n-gun game engine for the Snes, and I just don't get it. Everywhere I look, everybody says the Snes is far too slow to handle intense action games. Some how, I must be doing something different than other programmers, because nomatter what I do, it feels like I have a vast amount of cpu power left. BSNES is supposed to emulate slowdowns, isn't it?

I'm talking about systems that have a second cpu for audio. Most developers took cpu speed litterally as gameplay speed. Look at the average shmup on the Snes and the background usualy scrolls 1 pixel per frame. Then look at the average Sega Genesis shmup, and the background scrolls 2 pixels per frame. Just moving a background at faster speed isn't going add any extra slowdown to the game. And no, when the Super Nintendo is accessing it's 2.68Mhz, it doesn't slow the game to 3/4 it's full speed either. All videogames are fixed at 60 fps, and the cpu is timed with each frame. I've heard one guy trying to make a theory that the reason why Sonic moves slow underwater, is because they switched from the 68000 to the Z80 in that level. It does not work that way. Sonic moves slower underwater because the game physics are, if sonic's y coordinate is greater than waterlevel line, his coordinates will move by half their velocities. It's all mathematically done.

I honestly think cpu speed is overrated. When I'm programming it always feels like I have a galaxy of cpu time left within every frame, even with just a few Mhz. Sure things like data compression and some special effects like scaling and rotating sprites, take a lot of cpu time, but that is what the work-ram is there for.

The Lynx has 64 kB of DRAM in it, not 16 kB, which is good since that's the only memory the CPU can access directly (data had to load from ROM into RAM -due to the console originally being designed to load from tape iirc) Also, it's a 65C02. Going console and with a 65816, you could probably go up to at least 256 kB. (it is DRAM after all, and shared memory) But for the display, I'm not sure how the chipset would have handled higher resolutions (or higher color depth), not sure if higher clock speeds would have been possible -which should have helped for some things. Sound hardware would need to be beefed up though, simplest is probably adding a Yamaha FM synthesis chip. (various available, several in the low-cost range) I'm pretty sure that if the Lynx could have been adapted into a home console they'd have tried it though. It was a pretty low cost design for that market, so would have fit pretty well in line; if decently high resolutions were possible (at least 256x192, 320x224 would be nice) and the hardware was powerful enough to make smooth games at that then it could be a good idea for the time; probably at a fair disadvantage to the SNES and Genesis (with some trade-offs), but definitely at a cost advantage. Otherwise an ST derived console (with the BLiTTER) would probably have been better -though a bit weal for 1990. (the Panther was not a good option in the cost range they wanted -with a dual bus design and at leat 64 kB of SRAM, maybe it would have been nice, but that's way past the cost range Atari wanted for it -granted contemporary consoles had that much SRAM, and more -perhaps not as fast rated though) What exactly is the pixel fill rate for the atari lynx?

What is the point of this thread exactly? Rate systems' graphical power by units of made-up buzz words that were completely made up just for advertising their systems.

I like the idea of consolized Atari Lynx. Handheld Atari Lynx specs- cpu: 3.58Mhz 6502 resolution: 160x104 colors: 16 out of 4096 ram: 16 kB Console Atari Lynx specs- cpu: 3.58Mhz 65816 resolution: 256x224 colors: 256 out of 32876 ram: 128 kB

How about optimizing code for making it easy to write efficient code.

I also consider using creative use of DMA, V-RAM, fitting a sprite frame within the least amount of 8x8 tiles, and recycling tiles between frames, to be another type of optimization. I'm writing my own game, and I'm planning on simulating sprite rotation by drawing out 1/4 the rotation steps in ROM, using an algorithm to make the cpu rotate each rotation frame by 90 degrees into RAM for another 1/4, and using x and y flips for the other 1/2. Symetrical sprites make it even easier to fake rotation.

Why is it that whenever I use the phrase "optimizing code," people always assume I'm refering to fine-tuning or nit-picking code? Fine-tuning or nit-picking barely speeds up code at all. Archectural optimizations and taking different approaches make far more of a difference, so why do small optimizations always come to people's minds whenever they hear the word "optimize?"

And the size of the vram.

In my opinion, all 2D games should have at least 15fps of animation. 99% of 16-bit games don't follow this rule.

Another question. How the hell did the old myth that the Super Nintendo cpu was slower than the Atari 2600 happen in the first place, and why do so many keep people beleiving it after they've been proven wrong over and over again?

I'd find out what moronic company hired a 16-year-old to design their next console and short their stock. Well, did any company hire a 16-year old, that your refering too?

I want to know if you think it can handle this game.

Another question, in most fighting games of the time, why did punches and kicks only use one frame? There could've had been at least 3 frames if they recycled the first two frames for every different type of punch, and only have the last frame differentiate between punches.

Joe Redifer as a joke pretends to be a technical genious, yet half the internet takes him seriously and thinks he's for real.

How whenever a game had huge sprites, the fluidness of the animation always suffered? Stupid little kids look at game magazines and get impressed by giant sprites, but I always knew that big sprites always meant the animation is going to be crap.

Was it this? http://uncyclopedia.wikia.com/wiki/Atari_1300

What systems have you programmed before? I find Super Nintendo to be very tedious to program without using macros.

In addition to the few uses as a full background layer, but it's often used for simple overlay graphics too (for status bars and such), Street Fighter II uses it for the health bars, Star Fox uses it for the Star Fox emblem on the title screen, etc. I find that to be pretty dumb that it was only used for status bars. Why didn't they just set up an IRQ or H-DMA to change it from a status bar to a parallax layer after the last scanline the status bar is visible?

The 3rd background layer was hardly ever used by anyone other than Rare, Factor 5 or Virgin. And no, Street Fighter 2 uses line scrolling and that can be done in every mode. The only times I remember tile-per-offset actually being used was the giant zombie turtle boss in Contra: Alien Wars, and the snake boss in Aladdin.

Too bad nobody actually used the third layer. Too bad nobody actually made the tiles scroll seperately.

The SNES's PPU is either 5Mhz with two 8-bit data buses, or a 10-Mhz with one 8-bit data bus. If Nintendo used a 20-Mhz PPU with an 8-bit data bus, they could've had 32 8x8 tiles of rotatable and scalable sprites accross the screen, and there can be daul "Mode7" layers, or 4 bgs with tile-per-offset scrolling.