I'm sure many of you guys program for other systems too. I'm pretty sure there is some interest in at least some of the other Nintendo platforms, such as the SNES, GB/GBC and the GBA.
What I want to ask you is, how do you handle working on projects on different platforms? I am pretty bad at managing projects, and often have too many of them at the same time and work a little bit on each one until I get tired of it, and then put it aside for a while. The problem is that whenever I return to an old project, I start it again from the ground and throw away everything that was previously done. Needless to say, I never complete anything.
I've been a bit worried the last few days, 'cause i've been developing an increasing interest in the Z80 processor and a few platforms that use it. I don't want to abandon the NES, specially since I've never completed one single cool program for it. I have many many ideas for it.
I guess this is just temporary, isn't it? Have any of you felt excited about other platforms, but eventually returned to the good old NES? I kinda feel like I'm "cheating" on the NES... Is that weird?
There is no "cheating on" the NES unless you're being paid. Work on what you want to work on. Even I have time to make nearly 7000 posts over at
That Other Board.
I flit from project to project all the time. I don't get much done in terms of end results, but I learn a bit, and bring it to the next thing I work on.
Having used several debuggers to change all types of assembly, I have a good idea of what I need to be productive on small projects. I won't beat out anyone else here who writes their own players and music and compile them, but I can do a lot of quick-and-dirty stuff to debug from different angles.
I spend more time looking for ways to use and test my skills on a small scale than I do trying to develope large-scale ones. I can assure you that I never expected to be able to rip NSF files until I found an adequate program for hacking Game Genie codes, and was inspired to go just a step further to get something I'd wanted since NSF files appeared on Zophar's Domain.
Whether or not it's temporary, look at your history, eg. as a kid, did you get a new hobby/sport every few months never to look back at the previous ones?
Go for whatever interests you most. (get in shape for MSXdev'06
)
hap wrote:
get in shape for MSXdev'06
How did you know I'm interested on the MSX?!
But it's true. I got an old MSX1 computer from my girlfriend (it was all dusty locked in a closet) a few months back.
I intend to prepare a little something for MSXdev'06, yes! =)
If the PSX is the PlayStation, is the MSX the MoleStation?
[/nensondubois]
tepples wrote:
[/nensondubois]
So true! =)
Quote:
How did you know I'm interested on the MSX?!
Because I am too, though in the emulation branch (I've assisted with the unfortunately currently inactive emulator NLMSX). Every sane MSX fan visits msx.org, and that's where I saw you posting.
hap wrote:
Every sane MSX fan visits msx.org, and that's where I saw you posting.
I just didn't think many people would be interested in it. It is a fairly unknown system in most places...
I'm still trying to get the hang of it, it is so strange to be a newbie again!!!
It's not unusual to acquire a taste for other systems (kinda like in marriage, heh.) so don't worry.
Er, actually, you might have something to worry about. It's just like learning another language. For some people, they can learn a new language, and it doesn't interfere with their old language. Overall, it may boost their intelligence, even.
Some people, however, encounter destructive interference, where learning a new language interferes with their use of the old language. And both are spoiled.
I don't mean to get all serious, but it could happen.
Anyway, I had fun learning Z-80 when I had the itch to program for S*GA systems, and then when I had had enough, I went over to the PC-Engine. Sometimes I even look at NES 6502 code.
You tend to forget opcodes a bit, and which register is on what system, but overall, it doesn't take more than a few hours to get back in the mood of your favourite system.
ccovell wrote:
It's not unusual to acquire a taste for other systems (kinda like in marriage, heh.) so don't worry.
That's why I said I kinda feel like I'm "cheating on" the NES... O_o
Quote:
Some people, however, encounter destructive interference, where learning a new language interferes with their use of the old language. And both are spoiled.
Yeah, that does worry me a little bit...
Quote:
Anyway, I had fun learning Z-80 when I had the itch to program for S*GA systems, and then when I had had enough, I went over to the PC-Engine.
I'm liking the Z80 so far, but I'm so used to the 6502 that Z80 code doesn't smoothly flow from my head yet, there is some kind of "conversion step" (the same happens when you learn a new language, as you said... you must get to the point where you think in that language, and not perform a really quick translation) and I must get past that. The SMS seems to be a nice system to program for (and I got 2 of them at home, wich is a plus for me), I plan to take a look at that sometime soon. I like the PC-engine very much, but unfortunately I do not own one.
Quote:
opcodes a bit, and which register is on what system, but overall, it doesn't take more than a few hours to get back in the mood of your favourite system.
You are right. This happens to me with whatever I have ever learned, so why would this be any diferent?
tokumaru wrote:
I'm liking the Z80 so far, but I'm so used to the 6502 that Z80 code doesn't smoothly flow from my head yet, there is some kind of "conversion step"...
Yeah, I too had a bit of trouble looking at all the LDs and understanding what they did. Continuing the language analogy, 6502 and Z80 mnemonics are a bit different. 6502 seems to be subject- or agent-oriented, with LD
A, ST
A focusing on the memory location and work being done to
it; whereas Z80 seems more predicate-oriented, with the
action being done taking primacy, and the registers that this LDing is being done to having secondary importance. But that was just my impression.
So why not make a set of macros that use 6502 style mnemonics to produce 8080/Z80/Sharp80 or SPC700 object code? If you need inspiration, look at ARM assembly language, which shows the company's 6502 roots.
Because then we don't properly learn! =)
I think the basis of any assembly language are the same, even if all opcodes and tricks are different.
You would have to sustain the best level on everythig for your own good, so don't think too much about something else to forget the NES, just make sure to keep first a global aproach of your problems, then code them in the language you must.
Yeah, but when you code for older systems, you gotta think about the specifics of the target platform.
You just can't go very far before you must start thinking about the implementation of the ideas. I mean, you can come up with the plot for a game, the characters, etc. But the minute you start thinking about the levels and how big and complex they are, you must think platform-wise.
Hell, with systems like the MSX1 you can't even come up with characters without thinking about the limitations of the platform, as it's sprites have only one color. So, in the best case, you should be able to come up with a character that can be represented well with 2 layers of sprites, if you don't want to compromise the other sprites in the same scanlines too much.
For older computers, the kind of game you develop has everything to do with the platform, IMO.
Well, yes or no. You may try to get as global possible on your approach.
Of couse, you have to draw tiles with the system in mind. But how you assemble tiles in your game engine and all calculations that are done are platform-independant. Only tricks to simplify things aren't.
Bregalad wrote:
Of couse, you have to draw tiles with the system in mind. But how you assemble tiles in your game engine and all calculations that are done are platform-independant.
No it isn't. Game Boy Color can use tile objects of odd width and height; NES can't.
I didn't mean what you're saying. Maybe you're right, I should clarify things a bit more :
- All maps and tile related stuff is pretty much platform specific, but not totally, as from platform to platform, some things are common
- All game engine main approach should be the less platform-specific as possible. Sure, your engine has to draw stuff to the screen and run sound on a specific platform, but the main idea will keep the same regardless of the platform.
- All that have to do with calculations, collision detection, events, etc... isn't platform specific, and that is the most "annoying" part of coding a game in my viewpoint.
I don't know Bregalad. The importance of the platform during design seems to be more important than just sound and graphics.
Much of the structure of the game has to do with the platform. A very important thing in a game engine, for example, are the level maps and the scrolling engine. There are many things you have to decide when designing these. Will the levels be run from ROM or RAM (pretty much impossible on the NES without WRAM)? Compressed or uncompressed? How fast (how much data) can you write to VRAM each frame (affects scrolling)? What is the range of your index registers (will play a part on how you'll arrange/compress the data in ROM)? What kind of bankswitching is avaliable (also plays a part on the overall organization of the data)?
I just can't go very far with the design of a game before entering the platform specifics. Of course, you could for example think about the physics, battle engines, and such logical things without thinking about the platform, but i guess that's it.
You have to face it, with systems that are low on resources (CPU and PPU speed, memory, etc) you have to be very careful when designing a game.
Of course it all depends on the kind of game you are coding. Today, many years after the time when 8-bit games were the newest thing around, we tend to push the old platforms to their limits, trying to implement ideas not used back then, ideas that tipically require more resorces than avaliable in older systems. With clever coding, we can overcome many of the limitations, but you have to know the machine very well.
If you stick to coding pac-man or pong, then there is not much reason to think about the platform as these are games that require very little resources.
I think it's all about how "powerful" the game is. You can't code a "powerful" game in a machine that's not as powerful, unless you know it's limitations and can think of clever ways to overcome them.
I mean all game logic isn't platform specific.
You should of course design your game with the limits of the platform in mind (dont try to render a millions of polygons with the NES). But you shouldn't approach your code with platform specific opcodes, but with a main global idea of wich calculations or transfters are done, why, how, etc.. And then you can write routines that does the work on the sprecific platform. I think it's obscure to explain that, and I hope you understood well enough.