This thought came to my mind. Did any developers program NES games using other 6502-based computers with more powerful graphics chips, counted animation frame, take out frames or tiles that wouldn't fit in the NES's CHRROM, then take the ASM code for the game logic and write the PPU code after they made sure everything would work?
I've never programmed the NES, but for the SNES, animation was my #1 problem, and it would've made sense doing it this way.
Technically, at least in modern programming, your game engine and your graphics engine are supposed to be completely seperate. I.e., your game engine can run even without any of the graphics subroutines. Given this, I can imagine someone doing what you said. More than likely though, I'm thinking they just used special copynes-like dev NESes and just tweaked their code on that.
Were there ports from C64 or Apple II to NES? Yes. Lode Runner is among them.
The problem comes when you have to deliver your game logic across platforms with 6502, two different 8080 derivatives (one by Sharp and one by Zilog), 65816, and 68000. That's why Koei just bit the bullet and wrote its games in C, according to NovaYoshi's educated guess. A similar problem occurs when trying to make modern games that work on Windows Phone 7 and Xbox 360 (verifiable CIL only), BlackBerry (verifiable JVM bytecode only), and everything else (native code preferred).
tepples wrote:
Were there ports from C64 or Apple II to NES? Yes. Lode Runner is among them.
The problem comes when you have to deliver your game logic across platforms with 6502, two different 8080 derivatives (one by Sharp and one by Zilog), 65816, and 68000. That's why Koei just bit the bullet and wrote its games in C, according to NovaYoshi's educated guess. A similar problem occurs when trying to make modern games that work on Windows Phone 7 and Xbox 360 (verifiable CIL only), BlackBerry (verifiable JVM bytecode only), and everything else (native code preferred).
Not sure if you understood my question. I'm talking about using a different computer for placeholder graphics so you knew how many frames of animation your working with, before you program the PPU handling code.
psycopathicteen wrote:
I'm talking about using a different computer for placeholder graphics so you knew how many frames of animation your working with, before you program the PPU handling code.
I think you are putting way too much emphasis on animation frames. I know it has been a problem for you, but I don't think this was a major concern for most developers, specially on the NES where the animation graphics are either all loaded in at all times or simply bankswitched in as necessary. Few NES games dynamically update animations in CHR-RAM, which is what actually complicates things (I'm doing this in my game, and I agree it's a bit hard to get right). But even then it's not such a big deal.
tokumaru wrote:
psycopathicteen wrote:
I'm talking about using a different computer for placeholder graphics so you knew how many frames of animation your working with, before you program the PPU handling code.
I think you are putting way too much emphasis on animation frames. I know it has been a problem for you, but I don't think this was a major concern for most developers, specially on the NES where the animation graphics are either all loaded in at all times or simply bankswitched in as necessary. Few NES games dynamically update animations in CHR-RAM, which is what actually complicates things (I'm doing this in my game, and I agree it's a bit hard to get right). But even then it's not such a big deal.
Well I haven't programmed in a while because I lost interest in it. I guess part of the reason why I put so much effort on animation frames, was because I felt I needed to prove Sega Genesis fanboys that the SNES can run fast action games dispite what has been said about it's CPU speed, and animation is an important part of what makes an action game look fast.
I didn't say you were wrong for focusing too much on implementing good animation on the SNES, just wrong for assuming this was such an important thing for NES developers back in the day, to the point they'd be "counting animation frames on more capable 6502 computers" or whatever. They probably did deelop/debug some code using other 6502 machines, but I don't think this had anything to do with animations.
Quote:
Well I haven't programmed in a while because I lost interest in it. I guess part of the reason why I put so much effort on animation frames, was because I felt I needed to prove Sega Genesis fanboys that the SNES can run fast action games dispite what has been said about it's CPU speed, and animation is an important part of what makes an action game look fast.
Then I'm 100% on your side : Screw you Sega Genesis fanboys !!
More seriously, first I don't know many computers which are more powerful than the NES and uses 6502. I'm pretty sure Apple II and C64 are less "powerful" than the NES. Also they have completely different screen resolutions and modes, and porting the graphics from one platform to the other would end up a total nightmare. In fact it might end up less hard to port code from one processor to another than port graphics with totally different screen modes.
I guess the PC engine uses a 6502 and is more powerful than the NES. Although I know basically nothing about this machine. Also the SNES uses a 65816 which can be retro-compatible with 6502.
Even if you'd use a PCE or SNES to prototype a NES game, what would you gain from it ? You could do better graphics and more calculations per frame. But it wouldn't change the difficulty to code the game, and in the end you'd have to "downscale" it to the NES which sounds hard.
So I guess you'd add yourself a lot of useless work.
With my programming on the 6809, which is pretty much a 1/2 sized 68000, it's awesome. In areas or more complex games, it can do so much more work faster. Not to mention the sheer amount of different sized registers, pointers, multiple stacks [In the 6809 at least], etc. Plus with the Genesis, you have a Z80 just for sound. And the 68K is way more ready for arithmetic than the 65816. It's be awesome if you could make a SNES game that is as good, but I don't think you'll be able to do as much at all. But you can probably make a better game, as except for the CPU, the SNES kills is in graphics, and IMO even sounds, quite often. So the power is useless when it doesn't look and sound great. But anyway:
I think that'd be cool to do, but yeah the downgrades and changes to take advantage of better hardware might not be worth it. Yeah, the main engine mainly stays the same, but the subroutines and music engine and graphics engine all would probably need rewritten. That sounds like a nightmare to me, especially if you take advantage of the hardwares layout, because then you may also have to change up your main engine, and you'd be writing the game essentially from scratch again. I think it's a neat idea, but I won't be doing it any time soon, good luck!
Quote:
Even if you'd use a PCE or SNES to prototype a NES game, what would you gain from it ?
Exactly. A game developed for the NES/Famicom should be developed from the ground up with the target system's limitations in mind (so you can specifically code around them and/or hide them). The PCE cpu is quite a few revisions away from the 6502 used in the NES (instructions, registers, etc), but it's the actual speed that's fairly big difference (1.79mhz NES vs 7.16mhz PCE).
Did someone mention sticking a 68k into the NES? It's wouldn't solve much. The surrounding/supporting video hardware is still a
fairly big performance influencing factor. A 1.79mhz 68k isn't going to be as fast as you think compared to a 1.79mhz 6502, for the NES. The 68k is powerful, but
slow. The 65x is extremely fast but
simplistic (direct addressing with free indexing and the ZP registers for indirect addressing are the real meat of the performance).
Bregalad wrote:
Even if you'd use a PCE or SNES to prototype a NES game, what would you gain from it ? You could do better graphics and more calculations per frame. But it wouldn't change the difficulty to code the game, and in the end you'd have to "downscale" it to the NES which sounds hard.
So I guess you'd add yourself a lot of useless work.
I mean more powerful in terms of flexibility, not more powerful in terms of graphics.
SNES PPU is powerful in terms of graphics, but weak in terms of flexibility.
Maybe we should move this to SNESdev or general discussion, because I was refering to ALL classic systems, I was just using the NES as an example. This isn't exclusive to NES.
3gengames wrote:
With my programming on the 6809, which is pretty much a 1/2 sized 68000, it's awesome. In areas or more complex games, it can do so much more work faster. Not to mention the sheer amount of different sized registers, pointers, multiple stacks [In the 6809 at least], etc. Plus with the Genesis, you have a Z80 just for sound. And the 68K is way more ready for arithmetic than the 65816. It's be awesome if you could make a SNES game that is as good, but I don't think you'll be able to do as much at all. But you can probably make a better game, as except for the CPU, the SNES kills is in graphics, and IMO even sounds, quite often. So the power is useless when it doesn't look and sound great. But anyway:
I think that'd be cool to do, but yeah the downgrades and changes to take advantage of better hardware might not be worth it. Yeah, the main engine mainly stays the same, but the subroutines and music engine and graphics engine all would probably need rewritten. That sounds like a nightmare to me, especially if you take advantage of the hardwares layout, because then you may also have to change up your main engine, and you'd be writing the game essentially from scratch again. I think it's a neat idea, but I won't be doing it any time soon, good luck!
I already proved it was possible to make a fast action game on the SNES a long time ago. I just didn't finish the game.
http://www.youtube.com/watch?v=5P8dH64m2Cc
psycopathicteen wrote:
I already proved it was possible to make a fast action game on the SNES a long time ago. I just didn't finish the game.
http://www.youtube.com/watch?v=5P8dH64m2CcWell of course it is possible. What about Contra III - The alien wars, Gradius III, etc... ?
Quote:
I mean more powerful in terms of flexibility, not more powerful in terms of graphics.
SNES PPU is powerful in terms of graphics, but weak in terms of flexibility.
May I ask what exactly you are thinking when you mention "flexibility" ? I don't see much gain from having a more powerful platform with the same CPU.... It might have better graphics audio that you won't be able to use, and the CPU might be faster. That's all that is going to change... I don't see the point.
Bregalad wrote:
psycopathicteen wrote:
I already proved it was possible to make a fast action game on the SNES a long time ago. I just didn't finish the game.
http://www.youtube.com/watch?v=5P8dH64m2CcWell of course it is possible. What about Contra III - The alien wars, Gradius III, etc... ?
Quote:
I mean more powerful in terms of flexibility, not more powerful in terms of graphics.
SNES PPU is powerful in terms of graphics, but weak in terms of flexibility.
May I ask what exactly you are thinking when you mention "flexibility" ? I don't see much gain from having a more powerful platform with the same CPU.... It might have better graphics audio that you won't be able to use, and the CPU might be faster. That's all that is going to change... I don't see the point.
Easier to work with, cleaner archetecture, less work getting something to be displayed.
I don't get it, why not just develop SNES code then? Wouldn't that be better than developing software that's kinda-NES-compabilte-but-not-really on an SNES?
Also, I think more to your original point, I've heard that some developers implemented and tested large portions of their games on Apple II GS's back in the day, then layered graphics and audio on top of it once they got over to the NES. I can't recall where I heard that, might have been the Pony Canon episode of Retronaughts.
Right, so that's just hearsay at this point.
psycopathicteen wrote:
Easier to work with, cleaner archetecture, less work getting something to be displayed.
It's called a PC. If you want to develop with less work, there you go. Virtually no limitations. Tons of languages and libraries to choose from.
The SNES is weak in terms of flexibility? What exactly doesn't "flex" for you? Are you annoyed by its limitations? You can bump up to PS1/Saturn, or PS2, or like I suggested just go with the PC until you feel the hardware can do what you want. The SNES is actually pretty flexible when you consider if you wanted to you could use the stock CPU as a slave solely for graphics/sound/input interaction with a separate CPU located in your cartridge, sort of like a SA-1. Only you could do whatever you want and use some really fast ARM CPU where you could program your game entirely in C and just write a slave program to run on the SNES to handle transfers from your ARM CPU to get your graphics and sound to the system and retrieve the input data from the controller and whatever else.
Part of the fun of developing for NES or SNES or any old console today is the limitations and nostalgia.
I disagree. C with a billion libraries to learn and choose from is so messy, crappy, and just mind blowing. I think consoles are the best choice for programming, since they have a set way they work and you're not slaving over libraries all day. Anyone else feel like that? I do a lot of Javascript programming and some C, but I prefer 6502 assembly all day.
I do agree with your point that there is a charm to working on a system like NES where there is pretty much nothing between you and the hardware. But PC development allows for much faster development in my opinion. Or atleast it is easier for me to throw together something on PC than it would be to do so for NES but if I had more practice maybe that wouldn't be the case.
I'd recommend PC development too if I could find a way around these disadvantages:
- Programs become obsolete when Microsoft makes incompatible ABI changes.
- PC has no culture of plugging in two gamepads for multiplayer.
- In my experience, PCs have far higher audio latency.
- The expected production values for a PC game are much higher than for an NES game.
I agree about working with consoles. The hardware is usually mostly the same (modulo, say, RAM bumps in later PSP models), and the libraries are much fewer making choosing easier. Not having to compensate for different screen resolutions in full screen, or RAM differences or OS differences, or processor speed differences is so freeing.
Even now that I'm capable of making PC games, I'd still prefer PSP. As for PC development being faster than NES, sure. But it's probably around the same speed as any other platform you can compile C for.
In order to write something to V-RAM you have to write to:
$2115 v-ram addressing mode
$2116,$2117 v-ram address port
$4300 dma mode
$4301 dma destination
$4302-$4304 dma source
$4305,$4306 dma legnth
$420b dma activate
Why didn't they just map OAM and palette into the v-ram address space, get rid of $4301, and combine $2115, $4300 and $420b into the same register?
psycopathicteen wrote:
In order to write something to V-RAM you have to write to:
$2115 v-ram addressing mode
$2116,$2117 v-ram address port
$4300 dma mode
$4301 dma destination
$4302-$4304 dma source
$4305,$4306 dma legnth
$420b dma activate
Why didn't they just map OAM and palette into the v-ram address space, get rid of $4301, and combine $2115, $4300 and $420b into the same register?
More flexability. I'd want the first way of doing it, you can move blocks of memory everywhere it seems. [I'm unfamiliar with SNES though.] And probably since the VRam used a square (2^x) ammount of RAM and taking up an extra 32-64 bytes will eliminate the usability of 1 full screen of VRam.
I'm not entirely familiar with DMA on the Super NES, but if it's anything like DMA on the GBA, it's essentially hardware-accelerated memcpy. DMA destination allows each channel to be used to copy to OAM, VRAM, palette, different scrolling registers, etc. And OAM isn't mapped into the VRAM address space on the NES, Game Boy, or GBA either. Your question sounds like "why is $4014 on the NES not in the $2000 block?".
$4301 isn't just the starting location, every byte in the DMA block get sent to that address, so DMA only does anything useful to registers $2104, $2118 and $2122. All three have there own corrisponding address register, so why don't they just combine all three and cut out the middle man?
I'm not sure what you are complaining about. I'm sure there was some hardware reason for why it was designed the way it was and it must have worked out given all the highly regarded games for the SNES.
You should look into the GBA because the GBA probably does things the SNES doesn't that you would like. It has a faster CPU and might have a more simple setup for graphics.
MottZilla wrote:
I'm not sure what you are complaining about. I'm sure there was some hardware reason for why it was designed the way it was and it must have worked out given all the highly regarded games for the SNES.
You should look into the GBA because the GBA probably does things the SNES doesn't that you would like. It has a faster CPU and might have a more simple setup for graphics.
Hardware reason: DMA was hacked on in the last minute.
Reason why I'm complaining about it: It takes longer to program.
I recall the SNES having HDMA capabilities (basically, a DMA where the bytes are transferred during each scanline's h-blank period, so it's kinda like a background process, but also allows things like mode-7's 3d effects to be possible if I'm recalling correctly). So maybe being able to freely specify 20 different start/end addresses would be beneficial for neato graphix trickz.
I also recall the NES's sprite DMA just simply copying bytes into $2004. Nobody complained about that.
I don't understand your complains. Normally you should write routines that displays sprites on the screen once, and use them as a tool for the rest of your program.
If it takes long, it takes long once. And you say it takes "longer". Longer than what ? I really don't get it.
Anyways if you dislike the (S)NES hardware nobody is forcing you to use those platforms.
psycopathicteen wrote:
Hardware reason: DMA was hacked on in the last minute.
Reason why I'm complaining about it: It takes longer to program.
I don't see any evidence that shows DMA was "hacked on in the last minute". The PC-Engine which came out before it had DMA. The MegaDrive which also came out before it had DMA. Why would Nintendo have added it last minute?
So what if it takes longer to program. It's not THAT big of a deal. Any game is going to involve alot of programming and design so it's not really unexpected that you have to deal with hardware quirks and such.
I think you'll find there is no perfect platform. Every platform has something that could be different to make it better. NES could have had more RAM, faster CPU, 4 nametables worth of VRAM, DMA, etc. SNES could have had a faster CPU, support a 320 pixel width resolution, etc. PS1 could have had more VRAM and RAM as well as a faster CPU. Thelist goes on and on.
You just have to work with what you have. Part of the fun is getting it working despite unfriendly design.
I just came up with a code that not only works for sprite animation, but also works for scrolling, and bg animation. It lets you upload large 1k chunks of v-ram, with only signifying the top 16-bits of the source address and the top 8-bits of the v-ram address. If there are more than 4 chunks, it continues the next frame so it is impossible to miss the end of v-blank.
Code:
!apple = "$0000"
!banana = "$0001"
!update_flag = "$0100"
!vram = "$0101"
!source = "$0102"
%macro move_chunk(source, vram)
php
rep #$20
sep #$10
lda <source>
ldy <vram>
jsr set_up_dma_list
plp
endmacro
set_up_dma_list:
ldx !apple
sta !source,x
sty !vram,x
ldy #$01
sty !update_flag,x
inx #4
stx !apple
rts
dma_chunk:
php
sep #$30
ldx !banana
ldy #$04
lda #$80
sta $2115
lda #$01
sta $4300
lda #$18
sta $4301
loop:
lda !update_flag,x
beq finish
stz $2116
lda !vram,x
sta $2117
stz $4302
lda !source,x
sta $4303
lda !source+1,x
sta $4304
stz $4305
lda #$04
sta $4306
lda #$01
sta $420b
lda #$00
sta !update_flag,x
inx #4
dey
bne loop
finish:
stx !banana
plp
rts