Jump to content

WIP: Wizard of Wor for NES


Recommended Posts

Hey guys, as I've alluded to in some status updates here on AtariAge, I'm working on a port of Wizard of Wor to the NES.


The following is a paste of the original post on NESDEV. The active thread is over there, because AtariAge does not have an NES homebrew subforum. If this is out of protocol, please let me know.


Primary thread here: http://forums.nesdev.com/viewtopic.php?f=22&t=16172




Hello everyone,

I'm working on a port of Wizard of Wor to the NES.

Source code here: http://github.com/tschak909/wow


I am an experienced software engineer with some 6502 experience, and I recently completed an Atari VCS game of Dodgeball, which can be found here: http://github.com/tschak909/dodgeball/ .. Have been a member of AtariAge since 2006 (and the Stella mailing lists since 1998), but this is my first venture into the NES homebrew community.

I initially was going to try doing WoW for the ColecoVision, but it turned out that Opcode had beaten me to the punch icon_smile.gif.. So... Didn't see one for the NES...and thought, why not? icon_smile.gif

I will be writing the primary game code in CC65, but for now, my concentration is on trying to make the graphics as accurate as possible. This is a challenge for me, as the original Astrocade based display runs at a different color clock, and therefore aspect ratio. (352x240) (As it happens, there are +2 more pixels in the horizontal direction, basically. so things need to be squeezed..also since I am targeting this for NTSC, there is less vertical space available.)

I've managed to take enough of a pass at the graphics to start laying out nametables so I can get an idea of scale (these static nametables won't be used as such, but hopefully will be generated programmatically).

Some of the chr's in yychr:

and in the middle of doing the first pass at the character screen. note the attribute clash. icon_razz.gif

I have been proceeding glacially at this for the last few weeks, but I am trying to be slow, patient, and precise. So i'll be working on the graphics for a while, until I can balance out accuracy for constraints... once I'm sure I can get everything squeezed in well enough, I'll start coding.

The target for this guy is an NROM-256. If I can do it smaller...great. I don't see a need to do a mapper.

Anyway, back to it. I hope all the American users have a good 4th of July. icon_smile.gif


(edit: images were obnoxiously large due to my hi-dpi display. Turned them into URLs to be polite.)



  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 months later...
  • 3 months later...

Picked this back up two weeks ago and have been steadily hammering away at functionality. Two days ago, I passed a major milestone to initial play ability in that the worriors could shoot the various monsters, as well as implementing the first pass of the blue player AI, both shown in the gif below.


I'm very happy that I've gotten to this point, as now there is indeed a light at the end of the tunnel, even if it is far away. :)


Code is as always @ http://github.com/tschak909/wow


Pushing onward...




progress GIF: https://media.giphy.com/media/xUOwG1iCofIHTiNFRe/giphy.gif


  • Like 5
Link to comment
Share on other sites

Wizard of Wor NES WIP:

I had initially planned to do three major optimizations. I have done two, and the result is dramatic. It seems I was at least spanning two or more frames worth of time to do my game logic. By simply re-arranging the game state arrays, and placing them into 6502 zero page, the game program logic as is, is running at full frame rate, speeding up by at least 200% ... WHAT A DIFFERENCE.

Basically before, I was building macros that did:

unsigned char stamps[NUM_FIELDS*NUM_STAMPS];

#define STAMP_NUM(x) (x*NUM_FIELDS)
#define STAMP_X (STAMP_NUM(x)+0)
#define STAMP_Y (STAMP_NUM(x)+1)


if (stamps[STAMP_X(i)]==... && stamps[STAMP_Y(i)]==... )

and so on...

Which was causing a 6502 software multiply (because no hardware multiply) on EACH AND EVERY read and write of game state, and I was doing this a total of about 220 times throughout the game logic.

I replaced this with:

unsigned char stamp_x[NUM_STAMPS];
unsigned char stamp_y[NUM_STAMPS];



if (stamp_x[i]==... && stamp_y[i]==...)


You can see, not only does this look cleaner, but it also runs much better, because the resulting calls literally become either direct X or indirect Y loads and stores. Which the 6502 loves to do..which is why I am KICKING myself for not doing it earlier. I KNOW this from doing 6502 assembler that it's better to keep arrays of the same data laterally together instead of in a c type struct or array, as it's simply an index change in the end.

I've pasted a copy of the latest ROM here, you can see it runs a fuckload faster, wowza! wow-post-optimize.nes

And of course, a GIF showing the new speed, it flies.. and I can now really start tuning the main game.


Damn, I feel good!


Edited by tschak909
  • Like 3
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.

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.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...