PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Punch on March 16, 2018, 05:53:21 AM
Title: Cross Platform development?
Post by: Punch on March 16, 2018, 05:53:21 AM
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 :lol:
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? :geni:
(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.)
Title: Re: Cross Platform development?
Post by: TheOldMan on March 16, 2018, 07:44:36 PM
Quote
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
Title: Re: Cross Platform development?
Post by: Arkhan on March 16, 2018, 10:04:41 PM
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.
Title: Re: Cross Platform development?
Post by: touko on March 16, 2018, 11:55:43 PM
Quote
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 .
Title: Re: Cross Platform development?
Post by: gilbert on March 17, 2018, 06:11:18 AM
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).
Title: Re: Cross Platform development?
Post by: Gredler on March 17, 2018, 09:39:27 AM
Have I glossed over how art is made and handled? I imagine you would need a lot of separate art assets
Title: Re: Cross Platform development?
Post by: Bonknuts on March 19, 2018, 03:58:19 AM
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.
Title: Re: Cross Platform development?
Post by: touko on March 19, 2018, 08:47:46 AM
Hi tom, glad to see you again :thumbsup:
Title: Re: Cross Platform development?
Post by: Bonknuts on March 20, 2018, 05:02:17 AM
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.
Title: Re: Cross Platform development?
Post by: Punch on March 20, 2018, 11:07:18 AM
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:
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. :lol: 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.
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.
Title: Re: Cross Platform development?
Post by: gilbert on March 20, 2018, 05:10:57 PM
Actually Iwasaki's blog (http://www.highriskrevolution.com/gamelife/) 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 (http://www.highriskrevolution.com/gamelife/index.php?e=501) 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.
Title: Re: Cross Platform development?
Post by: Punch on March 21, 2018, 01:46:25 AM
Actually Iwasaki's blog (http://www.highriskrevolution.com/gamelife/)
That's gold, thanks for sharing gilbert
Title: Re: Cross Platform development?
Post by: Punch on April 01, 2018, 06:56:45 AM
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. :lol:
2. How can you rip tilemaps easily with MAME? Asking for a friend.
Title: Re: Cross Platform development?
Post by: TheOldMan on April 01, 2018, 02:33:59 PM
Quote
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.
Quote
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?
Title: Re: Cross Platform development?
Post by: Punch on April 01, 2018, 02:47:27 PM
(http://i.imgur.com/tXaA15h.png)
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 :lol: :lol: :lol:
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 got reminded of Mednafen and it's actually pretty decent for debugging purposes. Suddenly this became fun to do (!!!). So many bugs left to find, lmao. But as you can see the underlying logic is working semi correctly and building for the NES still works properly as it should.
(http://i.imgur.com/soZQ3sQ.png)
EDIT: LOL I think I've figured out why there's a black stripe across the full screen fill and why the first column is also black: I'm probably writing the most significant byte of the tile first. Another bug slain, 9999999 more to go. :yuki:
Title: Re: Cross Platform development?
Post by: TheOldMan on April 01, 2018, 07:10:12 PM
Quote
I got reminded of Mednafen and it's actually pretty decent for debugging purposes....
Yes, it is. Make sure you go to the mednafen site and print out the debugger docs, so you have it handy. There's a lot of nice things you can do with it. And, as far as I'm aware, it's actually almost perfect emulation; if you see glitches when testing in mednafen, you will almost certainly see the same glitches on real hardware.
Quote
If you don't understand, chances are I won't either :lol: But I'll take a look.
At one time, I had a link to how the signal timing for NTSC video worked; how many pulses there were for various things, how long they needed to last, etc. I just didn't feel like working out exact timings in terms of how the pce did it. I do remember being puzzled by how the values got set (in the bios routines), until I walked through the actual code. IIRC, they are set based on the center of the screen. So, in theory, it should be possible to come up with a higher Y resolution; I'm really interested in something other than nnnX240, but haven't found out how. Yet.
Maybe I'll look back into that soon.
And, for the record, I'm not an electrical guy. I'm a programmer. But sometimes you have to know these things. Or at least, sort of understand them when you google them.
Title: Re: Cross Platform development?
Post by: Punch on April 03, 2018, 03:22:22 PM
(http://i.imgur.com/SdcF09I.png)
Bugs fixed! Just need to un-dummy the PCE version of the sprite handling routines and RLE compressed backgrounds. (and get rid of that ugly ass palette for once)
I got reminded of Mednafen and it's actually pretty decent for debugging purposes....
Yes, it is. Make sure you go to the mednafen site and print out the debugger docs, so you have it handy. There's a lot of nice things you can do with it. And, as far as I'm aware, it's actually almost perfect emulation; if you see glitches when testing in mednafen, you will almost certainly see the same glitches on real hardware.
I'm wondering if there are ways to load labels from the .sym file PCEAS generates into Mednafen. That would be useful (instead of having a second monitor with the file open searching for addresses lol.) I already have a nice cheat sheet printed out.
Quote
Quote
If you don't understand, chances are I won't either :lol: But I'll take a look.
At one time, I had a link to how the signal timing for NTSC video worked; how many pulses there were for various things, how long they needed to last, etc. I just didn't feel like working out exact timings in terms of how the pce did it. I do remember being puzzled by how the values got set (in the bios routines), until I walked through the actual code. IIRC, they are set based on the center of the screen. So, in theory, it should be possible to come up with a higher Y resolution; I'm really interested in something other than nnnX240, but haven't found out how. Yet.
Maybe I'll look back into that soon.
And, for the record, I'm not an electrical guy. I'm a programmer. But sometimes you have to know these things. Or at least, sort of understand them when you google them.
That's true, to this day I have no idea how to calculate exact Vblank time on the NES. I always use some conservative approximation (and you probably know how bad this is since it's so limited in that regard). Maybe it's time to actually try to understand that kind of stuff.
Title: Re: Cross Platform development?
Post by: TheOldMan on April 03, 2018, 07:15:57 PM
Quote
I'm wondering if there are ways to load labels from the .sym file PCEAS generates into Mednafen.
Unfortunately not. I generally keep the .sym file open in an editor (well, actually the .lst file) and flip to it when I need to. That way I can 'follow along' while debugging, and see the addresses for any variables I might want to check.
Quote
Maybe it's time to actually try to understand that kind of stuff.
Yeah, but right now i'm finishing something else up. The first thing I need to do is find the exact clock frequencies for the pce. From that I can start working out the times for the various NTSC signal parts. (In terms of the pce clock(s) )
Title: Re: Cross Platform development?
Post by: esteban on April 14, 2018, 01:15:32 AM
ASIDE: I fully support this awesome project (the brick game), because I know it will be a stepping stone towards BLODIA SPECIAL CD (forget about cross-platform, you want to target—as in limit—your potential audience to 3-4 humans and one really bored parrot).
:)
/aside
Title: Re: Cross Platform development?
Post by: Punch on April 14, 2018, 05:34:56 AM
A: trying to find a good scheme to make data overlays since PCEAS complains whenever I add something larger than 32k instead of just spilling over the data to other 8kb banks B: my keyboard's space bar is busted (again!)