Jump to content
IGNORED

Cat Quest 2600 (WIP)


Alp

Recommended Posts

Lately, I've had the idea of porting a cancelled NES game of mine, to the Atari 2600, just for fun.

 

I'm perfectly capable of coding this game in ASM, but unfortunately, the Stella emulator hates my computer (Open GL), so this will be Art / Design Notes, for now. No ROM tests, unfortunately. :(

 

After some reading, I've opted to use the "venetian blinds" interlacing technique, to potentially minimize sprite flickering. This also works surprisingly well with what I've designed for screens!

 

 

This is the current look of the title screen, though I've apparently made the text a few pixels too wide? I'll fix that, when I have some free time, to do so.

 

 

The visual design of the dungeons is heavily inspired by the Legend of Zelda. Slay Monsters, find Keys, unlock Doors, and kill a Boss enemy. You know, the basics.

 

 

I'm not sure how well this boss would work at the moment. But it would ideally function similarly to the Giant Snake boss, from StarTropics. Even leaving it's bones in the "Triforce Room", when it's slain.

(It sits in the doorway, wiggling it's body segments, occasionally spitting a fireball, to attack.)

 

 

The outdoors have barely been started, but I had fun with making this first dungeon! The visual theme is a castle, with a moat. Can you see how the colors are used?

 

 

Lastly, the caves in the world, will be dark without a lamp. They'll be traversable as you can see, but the monsters will be completely invisible! It's best not to get caught, stumbling around in the dark.

 

 

At the moment, I have 8-byte background "tiles" defined, with a multi-color option, that doubles the data size. These tiles are 32x32 blocks, with each color row defined in a single nibble.

 

I have some basic data structures defined, in an attempt to write fast tile-mapping, on this hardware.

Colors are swapped out, every other scanline, to allow for 2-color map screens. Potentially more, if a screen has sectors defined (such as the castle moat, in my mock-up, for example.)

 

I'm not really sure what would need to be cut back for this project. But for now, it's just a fun distraction from a NSFW RPG that I'm developing, with a friend of mine! :P

 

Thoughts are welcomed. Tear this ambitious idea to shreds, yo!

Edited by Alp
  • Like 11
Link to comment
Share on other sites

WOW! That game looks fabu..uh.. Really awesome!

 

These are just mock up screens right? Is this playable?

 

I've been thinking of a Zelda-like game for some time using the DPC+ kernel in VisualBatariBasic and I like what this looks like a lot! I don't think I would be nudging or prodding you at all to still do my own above head game as mine is quite a departure from The Legend of Zelda and also not a kyewt kitteh 'venture!

 

So you've got your graphics in binary externally? This reminds me of what might be done with TinyBasic.

 

 

OH...and on thoughts about what could be done different:

 

1. nothing

 

2. maybe two sprites overlapping for a couple more colors!?!

Edited by Papa
Link to comment
Share on other sites

After some reading, I've opted to use the "venetian blinds" interlacing technique, to potentially minimize sprite flickering. This also works surprisingly well with what I've designed for screens!

The venetian blinds will work fine for the background graphics (PF) but for the sprites it may impose too many limitations. Repositioning the sprite each scanline can only be done via HMOVE and that can only shift the position 7 or 8 pixels.

 

I'd also be concerned about getting that much data to the TIA. Asymmetric PF is 6 PF? writes. Both sprites will need the move, graphics, and color registers set. That's 6 more register writes. Move strobe brings the total to 13 and I probably missed something. So 76 cycles to update 13+ registers. The only way that could work is to use LDA immediate and STA ZP pairs. 13 * (2 + 3) = 65 cycles.

 

The next problem would be address space. Each scanline would consume 13 * (2 + 2) + 11 = 63 bytes. 192 * 63 = 12096 bytes of RAM to hold the entire screen. That's 6 2K RAM pages. Looks like those remaining 11 cycles will be used to bank switch to the next RAM page.

 

The final problem would be updating 12KB of RAM in overscan/vblank. Only the immediate value needs to be updated so it's only 13 bytes per scanline. 192*13=2496. The best thing to do here is just draw a black screen and dedicate all CPU resources to updating the screen buffer for a couple of frames.

 

With the 3E bank scheme I think this project could be feasible. You would just have to be very careful about where sprites can and can't go.

Link to comment
Share on other sites

 

On 10/1/2016 at 7:42 PM, Papa said:

WOW! That game looks fabu..uh.. Really awesome!

 

These are just mock up screens right? Is this playable?

 

I've been thinking of a Zelda-like game for some time using the DPC+ kernel in VisualBatariBasic and I like what this looks like a lot! I don't think I would be nudging or prodding you at all to still do my own above head game as mine is quite a departure from The Legend of Zelda and also not a kyewt kitteh 'venture!

 

So you've got your graphics in binary externally? This reminds me of what might be done with TinyBasic.

 

 

OH...and on thoughts about what could be done different:

 

1. nothing

 

2. maybe two sprites overlapping for a couple more colors!?!

Yeah. This project is just carefully constructed mockups for now. (and some rough code in a text file)
The graphics are indeed stored in a file! They look like this, in my document:
 
(I typed everything out in hexadecimal, for legibility.)

 

On the VCS, overlaid sprites would be overkill. I'd rather spend that space on the monsters and items.

 

I had actually experimented with multicolor sprites, to see how it would look while prioritizing depth/volume. It looks okay, I guess. But I'm not sure I like it. I may just stick with monochrome sprites.

 

 

Coincidentally, I had planned 2 Cat Quest games for the NES, and their eventual sequel, to be 16-bit (for obvious reasons) The console for the 3rd game was never decided on.

 

The 1st? A Legend of Zelda clone, utilizing the bare bones the NES has to offer (NROM Mapper), while presenting a much larger game! Suck it Nintendo! :P
 
It was a little more than half done, when I scrapped the project. I decided that the NES homebrew community are butts, and that I'd rather not waste my time with the likes of them.

 

The 2nd? A Wonderboy clone, with an Zelda II-like Overworld, a marriage of elements from both games.

 

...and the 3rd was planned to be a straight clone of A Link to the Past. Of course! :P

 

On 10/1/2016 at 8:12 PM, Papa said:

But it would totally blow peoples minds on the VCS!

 

On the 7800 it could be done BETTER (* begins briskly walking away while reaching into coat pocket...)

THAN on the NES!! :thumbsup:

If the scale of my cancelled NES game blew people's minds, just imagine what I could do on the VCS! :D

 

I have no doubt that it would look nicer on the 7800. Though, I have no experience with that machine. Coding, or otherwise. My only Atari experience was with the 2600, when I was a child.

 

On 10/1/2016 at 10:31 PM, ZackAttack said:

The venetian blinds will work fine for the background graphics (PF) but for the sprites it may impose too many limitations. Repositioning the sprite each scanline can only be done via HMOVE and that can only shift the position 7 or 8 pixels.

 

I'd also be concerned about getting that much data to the TIA. Asymmetric PF is 6 PF? writes. Both sprites will need the move, graphics, and color registers set. That's 6 more register writes. Move strobe brings the total to 13 and I probably missed something. So 76 cycles to update 13+ registers. The only way that could work is to use LDA immediate and STA ZP pairs. 13 * (2 + 3) = 65 cycles.

 

The next problem would be address space. Each scanline would consume 13 * (2 + 2) + 11 = 63 bytes. 192 * 63 = 12096 bytes of RAM to hold the entire screen. That's 6 2K RAM pages. Looks like those remaining 11 cycles will be used to bank switch to the next RAM page.

 

The final problem would be updating 12KB of RAM in overscan/vblank. Only the immediate value needs to be updated so it's only 13 bytes per scanline. 192*13=2496. The best thing to do here is just draw a black screen and dedicate all CPU resources to updating the screen buffer for a couple of frames.

 

With the 3E bank scheme I think this project could be feasible. You would just have to be very careful about where sprites can and can't go.

Hmm... venetian blinds are less ideal then? Alright, I can always revert the sprites back to solid color.
Honestly though, I kind of liked how it made the sprites match the style of the background. >.>
 
 
 
...and a mockup of the Dragon boss in action, because why not? :P
 
 
I've been carefully planning out a display kernel, that's as unrolled as I can get it, for speed purposes.
I'd ultimately be fine with adding some RAM for this game, but I'd otherwise rather stick with stock hardware, just for fun.
 
I could possibly lower the vertical resolution a tad, without losing too much detail? I may try that.
 

Yeah. Drawing colors over a black screen, is exactly what I had in mind, when I made the background color universally black. I do that with my 8-bit pixel art as well, to squeeze out more detail, with less.

 

I have no problem with restricting sprite location, I had planned for the game to be a bit slower paced.

 

On 10/2/2016 at 5:04 AM, Thomas Jentzsch said:

icon_idea.gif Try TAB/Video Settings/Render = Software or Direct3D

Huh, I'm not sure what you mean? Stella throws up a display error, and closes, without even opening a window!

 

I found the Z26 emulator, and that seems to work. But it's severely out of date? Hmm...

Edited by Alp
Link to comment
Share on other sites

Huh, I'm not sure what you mean? Stella throws up a display error, and closes, without even opening a window!

 

I found the Z26 emulator, and that seems to work. But it's severely out of date? Hmm...

Then try this command line parameter:

-video <direct3d|opengl|opengles2|opengles|software>

Link to comment
Share on other sites

Looks lovely, It's a shame you abandoned the NES version, the screens looked so lovely icon_tears.gif

I will be keeping an eye on this thread thanks icon_mrgreen.gif

Eh... Nintendo Age sucks, I'll say that much!

I've considered porting the cancelled NES version to Windows, relatively unchanged, but I don't really have the time, right now.

I'm also working on a NSFW parody of Hydlide, on the NES. We're keeping the "bumping" mechanics, if you were curious! :P

 

What works in hardware is sometimes completely different from initial concept art. I'd consider getting your display kernel up and going. If only to prove to yourself the time investment is worth it.

I'm way ahead of you there!

 

I'm already knee deep in the dead code, setting up my playfield line-drawing routine. It's going to be really ugly, but I think it'll work!

This isn't the first time I've needed to write fast, scanline-timed code. I've done "impossible" parallax scrolling on the NES, too! :P

 

The object-code, for updating everything in this game (including the player) is already finished-- at a mere 10 lines of ASM! :o

 

Mockups look really great. :) Nice to see more kitties on the VCS.

Yes! Cats are just awesome. This particular feline is my mascot of-sorts, in the furry community.

She originated in an Elder Scrolls-like RPG, from back in the day, as the default female build.

Link to comment
Share on other sites

After some reading, I've opted to use the "venetian blinds" interlacing technique, to potentially minimize sprite flickering. This also works surprisingly well with what I've designed for screens!

attachicon.gifCQ2600_Sprites_00.png

"venetian blinds" work for specific cases, such as video chess where the pieces don't move around:

s_VideoChess_1.png

 

or in stampede where the legs on the horse don't move independently from each other:

s_Stampede_2.png

 

But they're not useful for arbitrary sprites that move around on their own.

 

This is the current look of the title screen, though I've apparently made the text a few pixels too wide? I'll fix that, when I have some free time, to do so.

you could add the missiles and ball to turn a 48 pixel display into 51. The missiles will be in triplicate though, so would need to be hidden behind the playfield (set playfield to have priority, then color it black). Alternatively, if you accept the use of flicker you can make the title screen much wider:

post-3056-0-83915000-1475884518_thumb.png

 

The visual design of the dungeons is heavily inspired by the Legend of Zelda. Slay Monsters, find Keys, unlock Doors, and kill a Boss enemy. You know, the basics.

attachicon.gifCQ2600_11.png

Your status line is going to be ticky, will probably have to make some concessions there.

 

Your playfields with the alternating scanline colors work well with the limitations of the Atari. You can also make use of adjacent rows to simulate a 3rd color - the platforms on this level of Timmy! are drawn using Purple and Green, but they come across as something else:

blogentry-3056-0-93444500-1371168658.png

 

Isn't that much on the screen at once gonna be a flicker-fest on the 2600?

I don't see that many moveable objects in the mockups, shouldn't be any worse than Ms. Pacman.

Link to comment
Share on other sites

  • 2 weeks later...

Very promising mockups!

 

What about reducing the amount of black lines, e.g. like this:

Pw5chpy.gif

 

Also, I think some of the figures have too many color changes. The cat (?) at the bottom is perfect, though.

I don't understand where there are too many color changes, unless you mean running out of line cycles to change other registers? The 2600 is great at different color every new scan line.

 

The Playfield pixels mirrored use less cycles, or is it just less time critical when the write is made? I know asymmetric involves changing PlayField data mid-scanline.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...