Cross Platform development?

[Punch]

I kinda want my next NES project to be developed alongside a PCE version since I'm sure I'm going to be too damn lazy to port everything when the game is done. I was thinking about this a lot lately and I want to hear any ideas to make this viable.

As you already know the PCE is basically backwards compatible with NES binaries (of course the NES doesn't have all that PCE fancyness that is the internal bankswitch facilities, T mode, Set Decimal, etc.) so you would think it would be trivial to develop for both machines at once. But...

1. The video hardware is totally different from one another, it's not going to be trivial to port video related subroutines to the PCE, and good lord if you're trying to do fancy special effects.

2. Anything past 64 kb might complicate how you handle bankswitching for both consoles.

3. Music engine: I really have no idea what I'm doing with sound hardware and the only reason why my previous game had sound and music was because there was a Public Domain engine that I could use. This means that I'll have to make the same music twice, not to mention the hardware differences...

4. CD access vs. Nanosecond ROM access. If there's something in the NES game that requires a lot of bankswitching in a short amount of time that means that a CD port might not be viable.

5. There's high level C compilers for both machines but I'm sure that it would probably be much more incompatible with each other than anything in ASM


Do you guys think this is feasible, and any tips you can throw at me so I don't kill myself trying to do this?

(Koei had a shit ton of cross platform games involving all 8 and 16 bit consoles but I really have no idea how they did, I'm willing to bet that it's all interpreted code though.)

[TheOldMan]

so you would think it would be trivial to develop for both machines at once

Too bad bonknauts isn't still around. He did the megaman port, and had information about how
to convert things from the NES to the PCE. That would at least give you a place to start from.

I also wouldn't worry much about loading from CD vs ROM, at least to start with. You might be able
to load everything all at once, if you stay below 256K (or maybe 512K, I forget) with the system 3
card.

Other than that, I can only suggest trying to keep the hardware-specific stuff behind a well-defined
set of library functions. Things that can then be swapped for the different system builds

[Arkhan]

If you are going to do multiplatform music, consider MML, and try writing it for NES first, and then bringing to PCE where you get extra channels and can expand upon it.

MML is a portable(ish) music language.  You won't have to do TONS of work when going from platform to platform.

There exists PPMCK, and HuSIC, in addition to Squirrel for MML.   I am sure someone has to have written an MML player for NES that can be used in a game project.


I don't do NES dev but I would imagine they have libraries available.  What you might want to try doing is gathering both PCE and NES C libraries, and creating a layer above them that is toggled at compile time to pick which library call to make.    Or, the messier and probably required approach (because of video hardware differences and such), would be #def'd blocks to pick which code is used at compile time.

Microcabin released games on multiple machines, and it seems they wrote an intermediate language and had interpreters for various platforms, similar to what you're suggesting Koei did.   

[touko]

2. Anything past 64 kb might complicate how you handle bankswitching for both consoles.

bankswitching on the PCE is really easy and to have all in 8k banks help a lot .

[gilbert]

Hudson itself used an scripting language called IV in their PCE games, which was used extensively in especially games that speed is not the most concerned, like adventure games or RPGs (first or third party ones, doesn't matter, as it's in their official development kit AFAIK). With this they could easily design game events and data structures without using much assembly, just by using a parser/interpreter engine while executed. Without this, HUGE games such as Far East of Eden II simply couldn't be made.

I don't know whether they used IV in their Famicom (or even Super Famicom) games but it is a possibility, as they only need to have written parser engines on different systems so as to (re)use data formated similarly, especially most of the official development tools on the PCE were cross-platform supporting both Famicom and PCE (internal ones used by Hudson at least, the tools they provided 3rd party developers had the Famicom support removed so as not to confuse them).

[Gredler]

Have I glossed over how art is made and handled? I imagine you would need a lot of separate art assets

[Bonknuts]

How are you going to approach this? Are you going to have core code that's executable on both machines? I.e. shared source files. How are going to approach this compiler wise? Using CC65?

Honestly, depending on the size of this project, I would write a simple pre-processor that builds assets defines for the corresponding package (header for NES rom, tile format in bin, etc). Maybe even forces optimizations for PCE size (like force ZP addressing for certain labels if it's PCE option to compile). Write the pre-processor in whatever language you're comfortable with -> spits out a modified source code file(s) to be compiled.

[touko]

Hi tom, glad to see you again 

[Bonknuts]

Hudson itself used an scripting language called IV in their PCE games, which was used extensively in especially games that speed is not the most concerned, like adventure games or RPGs (first or third party ones, doesn't matter, as it's in their official development kit AFAIK). With this they could easily design game events and data structures without using much assembly, just by using a parser/interpreter engine while executed. Without this, HUGE games such as Far East of Eden II simply couldn't be made.

I don't know whether they used IV in their Famicom (or even Super Famicom) games but it is a possibility, as they only need to have written parser engines on different systems so as to (re)use data formated similarly, especially most of the official development tools on the PCE were cross-platform supporting both Famicom and PCE (internal ones used by Hudson at least, the tools they provided 3rd party developers had the Famicom support removed so as not to confuse them).

 That's pretty cool! I didn't know this. I messed around a few years ago where I made a simple scripting engine on the PCE side that allowed you to build a horizontal shmup. The script was interpreted in realtime. It was pretty fun. I could do low level stuff too, like load(tileset_label, length, vram_Address). I had slow versions, fast versions, etc. I could control speed across the level, linear, exponential, log, etc. Stop the scrolling, initialize events, etc. Set when an enemy would appear on the map either by time marker or by location marker (what point in the autoscrolled level you reached). It made tweaking and designing the levels much faster and easier. The script allowed for "parallel" commands via a queue, as well as priority level setting. I was going to introduce subscripts as well, say for when a dramatic scene was to happen in the background or foreground, but called simply by its label name -> basically run another instance of the interpreter to handle that sub-script for that scenario.

[Punch]

Thanks for the suggestions, I'll try to port my finished breakout-like game to the PCE first to see how much portable code can I keep between consoles. My game has a pretty rustic "scripting" system that kind of separates NES specific routines already:

https://github.com/AleffCorrea/BrickBreaker/blob/master/state.asm

(keep in mind that most of the code was rushed so there's going to be a lot of stupid stuff in it, don't judge me )

so you would think it would be trivial to develop for both machines at once

Too bad bonknauts isn't still around. He did the megaman port, and had information about how
to convert things from the NES to the PCE. That would at least give you a place to start from.

I also wouldn't worry much about loading from CD vs ROM, at least to start with. You might be able
to load everything all at once, if you stay below 256K (or maybe 512K, I forget) with the system 3
card.

Other than that, I can only suggest trying to keep the hardware-specific stuff behind a well-defined
set of library functions. Things that can then be swapped for the different system builds

I special summoned the banished Bonknuts into the board again, don't worry. And you're right about the CD, but since I want to maybe make some enhancements like extra graphical assets, cutscenes, audio samples, etc. we'll see if 256k will be enough. As for hardware specific stuff my previous game kind of does that somewhat.

If you are going to do multiplatform music, consider MML, and try writing it for NES first, and then bringing to PCE where you get extra channels and can expand upon it.

MML is very nice for this, I don't know if there's a NES MML library with a decent license but if there isn't it would be a nice excuse to finally start learning about the console's music hardware instead of just letting third party code take care of it.

I don't like the C stuff in the PC Engine Magickit and I think that the NES equivalent has even more limitations, but maybe I should give it a serious look later.

Have I glossed over how art is made and handled? I imagine you would need a lot of separate art assets

You can always go full lazy and just use the 4 color art of the NES version as is :-" :-" :-"

How are you going to approach this? Are you going to have core code that's executable on both machines? I.e. shared source files. How are going to approach this compiler wise? Using CC65?

Honestly, depending on the size of this project, I would write a simple pre-processor that builds assets defines for the corresponding package (header for NES rom, tile format in bin, etc). Maybe even forces optimizations for PCE size (like force ZP addressing for certain labels if it's PCE option to compile). Write the pre-processor in whatever language you're comfortable with -> spits out a modified source code file(s) to be compiled.

I'm using good old PCEAS.exe and NESASM, I see no reason to switch to "real" compilers at the moment. The pre processor idea sounds interesting, especially for setting up an automated pipeline for the project.

[gilbert]

That's pretty cool!

Actually Iwasaki's blog is a treasure of PCE development history, as he was a programming director in Hudson, involved with many CD projects, if you can read Japanese that is (I can read 60-70% of Japanese myself, the more Kanji the better), but web translation can help I think.

I don't know where he first started mentioning and explaining about IV, as I haven't read his enormous pile of articles yet, but it's mentioned many times in various places, that IV was extensively used (especially in CD games) and assembly codings were minimal. For example, he mentioned here about the assignment of programmers in a project, that starting from Far East of Eden II, they had one IV programmer writing IV scripts on a single state of the game (anyone played the game knew that it;s separated into various states/countries that you could travel around) so they probably had much more IV script writers than assembly coders.

[Punch]

Actually Iwasaki's blog

That's gold, thanks for sharing gilbert

[Punch]

ATTENTION DUELISTS:

1. I'm still trying to figure out what's my window for manipulating VRAM data. I heard that you can write/read data anytime, is that true? If so, what happens if I change a tile while it's being rendered in the current scanline?

I'll probably stick to writing during vblank for now (I don't even know how much cycles it lasts lol). Write outside of vblank in the NES and everything starts jumping up and down and your tiles get written randomly everywhere since the PPU reuses the registers you use to write to VRAM when rendering, it would be nice if that didn't happen here.

2. How can you rip tilemaps easily with MAME? Asking for a friend.

[TheOldMan]

I heard that you can write/read data anytime, is that true? If so, what happens if I change a tile while it's being rendered in the current scanline?

Yes, you can read/write 'anytime'. Dunno about during the active scanline, though. Never tried it.
I have, however, updated the vdc registers during the active scanline; sometimes if causes glitches
(like displaying the initial pixel, stretched over 2-3 pixels).
From what I remember, there are 'slots' for reading/writing, but I never really understood how it works.

I'll probably stick to writing during vblank for now

If you are going cross-platform, probably a good idea.

Afaik, the vdc registers are latches, with a seperate internal set for actual display.
You can check the tv signal specs if it really worries you. I *believe* the vblank period is at least 7 scanlines; I could be wrong there, though. (Raster irq value is 63 for first active display line, normally.
But I've never really been able to tell how much of that is the top blank area and how much is the
bottom)

I suggest you peruse the vdc register docs in the HuC stuff. There's a set of registers near the end that control the actual screen geomety; how many cycles each hsync/vsync pulse is, how many cycles
before the left edge of the screen, etc. I only vaguely understand that stuff - maybe you can explain it?

[Punch]

Another question: does anyone know what emulator actually supports debugging? I have bizhawk but the debugger doesn't work properly and it's just for show. Well at least I can see that the game managed to get to my character VRAM upload routine

I regret starting this but I can't give up until it's done. Wasn't revising my code to translate specific hardware code enough work already? Sigh

I only vaguely understand that stuff - maybe you can explain it?

If you don't understand, chances are I won't either
But I'll take a look.