AuthorTopic: Atari 2600 RPG mockup  (Read 11890 times)

Offline HughSpectrum

  • 0010
  • *
  • Posts: 283
  • Karma: +0/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #10 on: March 12, 2012, 08:48:54 pm
The one thing that would make the game implausible would be ROM storage, since it relies on a lot of bitmap graphics (I just show the ones for one type of wall and one type of enemy, but you can imagine there would be a lot more variety) as well as maps to navigate (some Atari 2600 games are lucky to even have more than one screen or level).

I'm also thinking about signing up to atariage.com's forums, just for kicks and giggles.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Atari 2600 RPG mockup

Reply #11 on: March 12, 2012, 10:11:42 pm
The one thing that would make the game implausible would be ROM storage, since it relies on a lot of bitmap graphics (I just show the ones for one type of wall and one type of enemy, but you can imagine there would be a lot more variety) as well as maps to navigate (some Atari 2600 games are lucky to even have more than one screen or level).

I'm also thinking about signing up to atariage.com's forums, just for kicks and giggles.

Oh they complain a lot on AtariAge about ROM sizes but there is bankswitching to help with that since only the amount of data processing is limited to 4K total while the overall storage memory footprint size is negotiable as even back in the day carts became bigger over time. I'm actually looking into special cart chips for exclusive font and text data storage uses, heck even Pitfall 2 "cheated" with a supplemental hardware addition to its cartridge. Plus I don't think its even possible to build a cartridge ROM that is literally 4K anymore just from the obsolescence of small capacities in electronics manufacturing, perhaps I'm wrong but that's what I see in most retroactively made peripherals for obsolete systems in that they are larger in capacity by default.

I will say this though, that despite hardware options for greater ROM/Memory sizes many are apprehensive to use them except for a few exceptions like using the extra memory within the Harmony cart for enhancing games.

Offline HughSpectrum

  • 0010
  • *
  • Posts: 283
  • Karma: +0/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #12 on: March 12, 2012, 10:19:09 pm
I'm sort of borderline on how I feel about that, as though I'm not staying true to how Atari 2600 games are, but at the same time a game like this would likely have used storage expansion even back then to promote itself as being a bigger game.

I still think size is a concern though.  Also there is no kind of saving system, besides the possibility of a password system (which I've never heard of for an Atari 2600 game, but I suppose is possible).

Offline Kasumi

  • 0010
  • *
  • Posts: 275
  • Karma: +1/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #13 on: March 12, 2012, 10:47:35 pm
Hmm... not art related and not Atari related, but I can't help but post. I would say it's definitely not cheating or not staying true to the console if the expansion hardware existed back then. NES was limited to 32KB for PRG, 8KB for CHR. (I know, I know, way more than 2600 already.) But almost every game anyone talks about does not have these limits. Even Tetris used more space! Super Mario Bros. does not, and it impresses me so much because of this.

I guess you could choose how you feel by how common the actual practice was. I feel certain hardware expansions are cheating for making NES looking mockups based on how expensive they were back then and how few games used them, but that's like 3 out of the like 20 non pirate ones I don't like.

Now for art related: I'm actually really impressed by the stuff here. Even coming from an NES programming background, I find these restrictions totally confusing but what you've got is looking really nice. That camp screen has all the information it needs, and it's readable.
I make actual NES games. Thus, I'm the unofficial forum dealer of too much information about the NES

Offline HughSpectrum

  • 0010
  • *
  • Posts: 283
  • Karma: +0/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #14 on: March 12, 2012, 11:08:28 pm
You have a point with mentioning other consoles.  I'll just go ahead and consider this an 8K game or whatever it would need.  A game like this is unorthodox for the Atari 2600 to begin with (unless you count the Swordquest games) so I can probably consider this a game that would have been bigger and premium of back then.

Thanks for the compliments as well.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Atari 2600 RPG mockup

Reply #15 on: March 13, 2012, 12:53:01 am
You have a point with mentioning other consoles.  I'll just go ahead and consider this an 8K game or whatever it would need.  A game like this is unorthodox for the Atari 2600 to begin with (unless you count the Swordquest games) so I can probably consider this a game that would have been bigger and premium of back then.

Thanks for the compliments as well.
Kasumi makes good points about Nes game capacities over the life of the console and the parallels with regards to added hardware. Please don't think I totally disregard authenticity or the impressive accomplishments of those that have made 4K games I just think the minimum size is way too confining and I am most pleased to see you mention 8K as a ROM size option since many a 2600 project benefit greatly from this simple upgrade.

Just saw your name change, I like the new name HughSpectrum but I had a lot of fun speculating about what a "Kittenmaster" would be. :lol:

Offline Dr. Kylstien

  • 0001
  • *
  • Posts: 25
  • Karma: +0/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #16 on: March 13, 2012, 06:07:22 am

Camp screen.  Heart = HP, S = Strength, I = Intelligence, D = Dexterity.  Made the stat scale so that only one digit would need to be kept track of for each stat.
The six sprite kernel spends the start of each scanline preloading the sprite pixels, and the rest of the scanline outputting them in realtime, which normally takes up all of the useful cycles in the scanline. So the differing colors between the characters and digits, and the updates on the playfield here, are improbable. (The realtime sprite drawing means you can't get any cycles from doubling the lines on the sprites either.) If you look at existing games that use this kernel, it's usually given it's own empty row as a score, or in more recent games a single color per line title graphic.

That said this looks really good. You might try rearranging things or using flickering to fix it for the hardware.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Atari 2600 RPG mockup

Reply #17 on: March 13, 2012, 03:52:07 pm

Camp screen.  Heart = HP, S = Strength, I = Intelligence, D = Dexterity.  Made the stat scale so that only one digit would need to be kept track of for each stat.
The six sprite kernel spends the start of each scanline preloading the sprite pixels, and the rest of the scanline outputting them in realtime, which normally takes up all of the useful cycles in the scanline. So the differing colors between the characters and digits, and the updates on the playfield here, are improbable. (The realtime sprite drawing means you can't get any cycles from doubling the lines on the sprites either.) If you look at existing games that use this kernel, it's usually given it's own empty row as a score, or in more recent games a single color per line title graphic.

That said this looks really good. You might try rearranging things or using flickering to fix it for the hardware.
Well that is true in that even if the numbers get there own Player object 4 digits is heavy multiplexing to occur along one line constantly which is usually why the six sprite kernel use gets its own isolated vertical zone or lane. Still you should check out the Title Screen Kernel, based on your setup you can make a 48X96 title screen image which isn't overly large for a cartridge ROM.

I'd agree about the differing colors since going from red to white along the same scanline would create a high enough cycle cost that it would be a problem. It's annoying but invoking a different color while multiplexing the same object at the same time is too much for the 2600, most of the Pac-Man work related to the multi-colored ghosts in later games like Ms Pac-Man up to modern homebrew Pac style games leveraged more sprite objects per ghost to avoid the limitations of multiplexing a single sprite so heavily.

In general when I can't for whatever reason isolate my HUD stats to there own vertical lane isolation and they go across the entire vertical field I usually use font characters made from Missile0, Missile1, & or the Ball with skipped scanlines on offset scanlines to avoid multiplexing flicker.
 However since you likely want those objects for projectile sprites perhaps you could use Playfield rendered numbers, they are kind of big and they would share the colors of the Playfield graphic on the other side of the screen without a mid-line color change split but they should be compatible under this rendering context.:)

Offline HughSpectrum

  • 0010
  • *
  • Posts: 283
  • Karma: +0/-0
    • View Profile

Re: Atari 2600 RPG mockup

Reply #18 on: March 13, 2012, 04:07:54 pm


I don't know if this is still problematic.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Atari 2600 RPG mockup

Reply #19 on: March 13, 2012, 04:27:43 pm


I don't know if this is still problematic.

Its a little squashed but this will work, however since everything is vertically stacked and isolated from each other your Playfield based font characters become unnecessary since both the categorical icon and its numeral could use the same sprite object since they never intrude on each others vertical zone(ref. Frogger). Still the numerals do have the advantage of being possibly rendered with more objects with less multiplexing flicker under this layout design if no projectiles are needed.

I do kind miss the old layout but this one has some strengths.:)