4 replies to this topic

[chjmartin2]

I am toying with the idea of doing a port or writing a game for the Aquarius.  I have thought about poker, written in basic but with machine language special effects.  I want to do a game in the Bloxel 80x72 mode.  I think it would be a good challenge to create animations and screen draws.  I think I would create a screen map in memory, directly modify that map, and then do a screen redraw from that map.  At least that is my first thought.  I never wrote a game before, and keep in mind that my assembly is very limited, but, I do know the Aquarius pretty well now in terms of memory/video and some sound.  

So... the question is, what do I tackle and what do you think of my Galaxian mockup below?



I realize that the score and high score look dumb as little blocks, I just got this far and decided to ask if it is too ambitious?  Also, isn't galaxian a z80 machine.  Could I disassemble it and try to port it that way, or am I better off with a rewrite.  I guess what I am asking is, where do I start?  Should I write it in C and compile it to Z80 or should I write it directly in ASM?

Thoughts and encouragement will be appreciated.  I am not confident I will be able to do this project, it may be too much for me.

Chris

Edited by chjmartin2, Sat May 14, 2011 2:22 PM.

[jaybird3rd]

Looks good to me so far.  I'd definitely recommend avoiding BASIC: it's just too slow, especially for anything that's going to be doing a lot on the screen, and it also requires you to run all your code from RAM, which limits your program space and requires a RAM cartridge for anything substantial.  Compiled code (either from C or assembly) can avoid this by using bankswitched cartridges.  I've been working strictly in assembly for my projects so far, but I do plan on using C for my next one, but it will probably require the creation of some Aquarius-specific libraries (for switching cartridge banks, for using the 8910 and reading the hand controllers, etc.)

Let me know if my screen editor would be helpful to you for laying out the graphics.  I'm still not planning on releasing it to the general public until I do a substantial rewrite, but I'll send you a copy for your own use if you'd like (with the proviso that it's still in a very early, very unoptimized state).

[mvdsteenoven]

chjmartin2, on Sat May 14, 2011 2:22 PM, said:

Thoughts and encouragement will be appreciated.  I am not confident I will be able to do this project, it may be too much for me.

Chris

Hi Chris,

The graphics looks nice. I would say just go and start with it and see how far you will get.
You did some amazing things with the graphics, and cool experiments with digitized sounds.This should be a walk in the park

Regs
Martin

[chjmartin2]

mvdsteenoven, on Mon May 16, 2011 11:36 AM, said:

chjmartin2, on Sat May 14, 2011 2:22 PM, said:

Thoughts and encouragement will be appreciated.  I am not confident I will be able to do this project, it may be too much for me.

Chris

Hi Chris,

The graphics looks nice. I would say just go and start with it and see how far you will get.
You did some amazing things with the graphics, and cool experiments with digitized sounds.This should be a walk in the park

Regs
Martin

Well... On November 27th, 2010 - I posted my first Aquarius program post.  Here we are now in May of 2011, and in the course of 6 months I have learned a few things, thanks to everyone's help.  I learned how to use and compile useful programs in Freebasic.  Now look, I realize that knowing an opensource QuickBasic port is not entirely useful in-and-of itself, but it is something I am comfortable in, and can "think" in the best.  I'm not sure if that skill could translate, but I am trying.  Second, I learned quite a lot about the Aquarius.  I know the memory map, how the color/character ram works.  I know how the VSYNC signal works, and how the emulator is flawed relative to the actual hardware.  I've learned how to write and compile a program in Z80 Assembly, albeit, the Aquarius implementation.  I've modded my Aquarius to output composite signal.  I wrote a program that simulates more colors and higher "resolution" that the original hardware allows.  My friend Jay sent me a cartridge that I can use and burn my own ROMs.  I bought an EPROM writer and ran my own custom code on the Aquarius.  I implemented a 1-bit dac player, but of course, wasted my time because somebody else had already done that.  I demonstrated Pulse-Width Modulation audio playback at 4 bits. (not sure if I posted that, but it did work)  

The problem is, I like to explore a lot of systems, and this has been a nice project, so I am struggling with moving on to the next thing.

So this is what I have decided.  I need to make an Aquarius Demo - something that uses the flicker mode, or some variation on it.  In addition, it will have to play music/samples of some kind.  Of course, it must run in 8k (maybe 16k) on a stock aquarius.  I think if I can do this, then I can move on.  I want to do something unique in both the video and audio effects in my demo.  I was thinking of building something like a one-note tracker.  Since the samples have to be delayed anyway, you could modify the frequency by varying the delay for the playback.  If I could get a really clean sample of a piano note, or drum beat.  Alternatively, I could grab 2 or 3 second clips at 1-bit and run them together.  Another limitation I want to place on myself is that I have to syncronize the visual effects with the audio playback and in some way use the audio data.  All of this, in 8K and 4 MHz.  I realize things have been done on other systems, but I haven't seen any Aquarius Demos - unless I am missing something.  Those are my thoughts...

[catsfolly]

Your "galaxian" style mockup looks very nice. Using only two colors per horizontal line for the enemy ships is a good idea - it limits the color problems you might have otherwise. You might have some color problems with drawing and moving the player ship, though.

I think C would be fast enough - I would recommend using C if you are comfortable with it.

If I were writing this game, I would approach it like this:

1. Write code to draw and erase the player ship.
2. Write code to move the player ship back and forth using the keyboard or controller.
3. Create an enemy ship that simply moves back and forth across the screen.
4. Write code to fire shots at the enemy ship.
5. Detect and handle collisions between the shots and the enemy ship.
6. Use everything I learned from steps 1-5 to rewrite the whole thing.
7. Add more enemy ships.
8. Dive bombing ships...

Just a thought..

David