Jump to content
  • entries
    7
  • comments
    21
  • views
    14,846

b*nQ

Sign in to follow this  
kenfused

1,610 views

I finally finished programming bonqlogo1.GIF and finally it was out the door a few weeks ago. Seems like it takes 90% of the work to finish the last 10% of polish. I did manage to sneak 2 1/2 easter eggs into it as well as the saveKey (or Atarivox memory card only) support. Now it's time to pick a new project. I am leaning towards another 7800 game. Maybe Super Pacman or maybe a platformer. I got some ideas for some scrolling platformer games, but I would probably have to spend a lot of times on some tools before I begin. Other options might be Qix for the 7800 or to do some more 8-bit computer to 5200 conversions.

Sign in to follow this  


14 Comments


Recommended Comments

All of those sound good. I would suggest a couple of 8-bit to 5200 conversions first. Maybe try to do one with Bryan's 256K board. I'd love to see another conversion like MULE.

 

Continued..

 

I had some more thoughts on this..

 

Some games to do and why.

 

1. Zookeeper on the 7800 would be great and and all the sounds are already done.

 

2.Convert the 5200 sounds of Donkey Kong and Jr. over to the 7800 versions because the sounds suck on them. Plus you could had the High-score cart code to them.

 

Allan

Share this comment


Link to comment

Qix, Super Pac-man or a platform game on the 7800 would be great. I enjoyed both your releases on the 7800. A platform game on the 7800 is something I would like to see. Qix is one of my favorite games and Super-Pac-man is a fun game to me.

Share this comment


Link to comment

Improved version of Donkey Kong and Donkey Kong Jr. would be awesome(improved sound and missing levels) and you could do it as a collection and have both games on one cart like the NES classics version.

 

You could do Donkey Kong 3 for it as well and put all three on one cart now that would be something to see thats for sure.

 

ZooKeeper is one that everyone would love to see i know i would or maybe a 7800 port of Crazy Climber or Star Castle just too many ideals to throw out there. :lolblue:

Share this comment


Link to comment
You know what would *really* rock? Qix on the 2600. I'd buy it.

 

Qix on the 2600 would require extra RAM. Even with extra RAM, some concessions would be needed. Especially given the risk of trademark issues, it may be better to use a slightly different game design (most notably replacing the bouncing bunch of lines with something else bouncy). The bouncing lines would be neat, but the only way I can see those working would be to use a 104x192 two-color "flickerscreen" bitmap. That might look okay, but it would require a lot of RAM.

 

If the bouncy object were a more conventional sprite, then it might be possible to use a color-striped playfield for the background and get by with something like a SARA-size RAM.

Share this comment


Link to comment
Qix on the 2600 would require extra RAM. Even with extra RAM, some concessions would be needed. Especially given the risk of trademark issues, it may be better to use a slightly different game design (most notably replacing the bouncing bunch of lines with something else bouncy). The bouncing lines would be neat, but the only way I can see those working would be to use a 104x192 two-color "flickerscreen" bitmap. That might look okay, but it would require a lot of RAM.

 

If the bouncy object were a more conventional sprite, then it might be possible to use a color-striped playfield for the background and get by with something like a SARA-size RAM.

RAM would even be pretty tight on the 7800, but I did calculate a board size close the 5200 version should be possible (narrow playfield and graphics rows would have to be doubled up).

Share this comment


Link to comment
RAM would even be pretty tight on the 7800, but I did calculate a board size close the 5200 version should be possible (narrow playfield and graphics rows would have to be doubled up).

 

I did some figuring for the 7800; QIX would be doable with standard RAM, but there would be some interesting tricks. The bouncing QIX would be its own bitmap (much smaller than the screen). The fill-screen would be done using character mode. There are less than 256 different patterns that can appear in a 4-line by 8-pixel area, assuming that the cursor draws in increments of 4 lines vertically and 2 pixels horizontally.

 

If the fill-able area is 128 pixels wide by 160 lines high, that would require 640 bytes of RAM to store. Not unreasonable at all. The QIX would need its own bitmap, but that shouldn't be too bad. If it fits in an area that's 40 pixels wide by 80 pixels tall, that would be 800 bytes. A little irksome, but not too bad. Note that I'm being generous and figuring single-line resolution and three colors for the QIX. Though I guess if the QIX splits in later levels that could complicate things. Maybe use two QIX, each a solid color. With the right display lists, that should work okay except for some strangeness where the QIX overlap on screen.

 

Alternatively, it may be good to draw the QIX at half vertical resolution. Unfortunately, there's no way to do that with standard RAM other than by using beam-chasing code. There's not necessarily anything wrong with beam-chasing (it can save memory for display lists) but I don't know what emulators handle it accurately.

Share this comment


Link to comment
Alternatively, it may be good to draw the QIX at half vertical resolution. Unfortunately, there's no way to do that with standard RAM other than by using beam-chasing code. There's not necessarily anything wrong with beam-chasing (it can save memory for display lists) but I don't know what emulators handle it accurately.

I had planned to do it at half vertical resolution in bitmapped mode. The playfield on 5200 QIX is around 128x80 [4 color] and would need about 2.5K for just the screen data.

Bad part it I would need 40 two row high zones for the playfield. (first entry would have row 0 and row 1, second entry would have row 1 and row 2, third entry would have row 2 and row 3). The QIX would be bitmapped (so they would have to be red, blue, or white and would be double line rez). Other items would be "sprites" (sparx and fuse). Luckily they are small and would not occupy too many zones at once each.

Share this comment


Link to comment
Bad part it I would need 40 two row high zones for the playfield. (first entry would have row 0 and row 1, second entry would have row 1 and row 2, third entry would have row 2 and row 3). The QIX would be bitmapped (so they would have to be red, blue, or white and would be double line rez). Other items would be "sprites" (sparx and fuse). Luckily they are small and would not occupy too many zones at once each.

 

I think you'd need 80 two-line zones, not 40, unless you want to use less than half of the screen vertically. Since each zone would take a minimum of 9 bytes (three for the DLL entry, and six for a minimal single-item display list) you're down to 300 bytes before you've even started. Just not going to work.

 

The only way to achieve a usable half-resolution screen on the 7800 is to either use extra hardware (as in Rescue on Fractalus) or else have a display list which gets patched for each scan line. I've tried that approach, and it works, but the code required for emulation is different from that required for a real machine. I was looking before at Missile Command, btw; QIX would have somewhat different requirements but the same principles would apply.

Share this comment


Link to comment
I think you'd need 80 two-line zones, not 40, unless you want to use less than half of the screen vertically. Since each zone would take a minimum of 9 bytes (three for the DLL entry, and six for a minimal single-item display list) you're down to 300 bytes before you've even started. Just not going to work.

 

The only way to achieve a usable half-resolution screen on the 7800 is to either use extra hardware (as in Rescue on Fractalus) or else have a display list which gets patched for each scan line. I've tried that approach, and it works, but the code required for emulation is different from that required for a real machine. I was looking before at Missile Command, btw; QIX would have somewhat different requirements but the same principles would apply.

Yea you're right with the 80. I divided by two twice. I think I was going to shrink it a little more horizontally. But yes, it seemed like a lot of work and a lot of compromises (small less colorful board) to fit it into 4K RAM. That's primarily the reason I didn't start it.

Share this comment


Link to comment
Yea you're right with the 80. I divided by two twice. I think I was going to shrink it a little more horizontally. But yes, it seemed like a lot of work and a lot of compromises (small less colorful board) to fit it into 4K RAM. That's primarily the reason I didn't start it.

 

4K? For some reason I was thinking you had 2K. 3K would buy you a 128x96 4-color bitmap pretty easily (if you don't mind beam-chasing). I think for best appearance the Qix should be in separate bitmaps from the background (using the tiling tricks I described earlier) so they could use their own colors. That would probably complicate things, though. Alternatively, you could design a different area-filling game which bounces sprites around rather than the line-monster. That might be the best approach.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...