WIP: Wizard of Wor for NES

[tschak909]

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

 

---snip---

 

Hello everyone,

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

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

About
-------

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 .. So... Didn't see one for the NES...and thought, why not?

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:
http://i.imgur.com/yCAV5KV.png
http://i.imgur.com/dS6gBmc.png

and in the middle of doing the first pass at the character screen. note the attribute clash.
http://i.imgur.com/rqKqq9T.png

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.

-Thom

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

 

---snip---

[Trinity]

i wan!

[Arenafoot]

is there a demo .bin (ROM) file yet?

[tschak909]

Initial screen test, here: dungeon rendering code is working, and is rendering a dungeon from data:

 

https://drive.google.com/open?id=0BxBzWnEPRL2HbmVJSGtiaXRrNDA

 

So you can get an idea of what to expect graphically.

 

-Thom

[Arenafoot]

Initial screen test, here: dungeon rendering code is working, and is rendering a dungeon from data:

 

https://drive.google.com/open?id=0BxBzWnEPRL2HbmVJSGtiaXRrNDA

 

So you can get an idea of what to expect graphically.

 

-Thom

Looks good to me! Keep up the good work!

[tschak909]

Status report video here:

 

 

-Thom

[ZylonBane]

What, no 7800 port?

 

Oh well, the NES should be a good home for it too.

[tschak909]

I will do a 7800 game at some point, but I don't think that Wizard of Wor would translate as well to the 7800 using either the 160 pixel or 320 pixel modes. It would probably be only a bit better than Roklan's 400/800 conversion.

 

-Thom

[tschak909]

A vid showing monster movement, although I need to rework box detection to allow actually going inside the box, and not just deflect upon immediately entering the box (some bias correction is also needed)...

 

 

-Thom

[tschak909]

A new update, I've done a few of these since Jul 31, but this is as of today.

 

 

-Thom

[sodarun]

Looks Awesome

[VectorGamer]

Wow this looks great!

 

Looking forward to playing this

[tschak909]

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

 

-Thom

 

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

[tschak909]

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)

...

 

stamps[STAMP_X(i)]=new_stamp_x_position;

stamps[STAMP_X(i)]=new_stamp_y_position;

...

 

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];

...

 

stamp_x[i]=new_stamp_pos_x;

stamp_y[i]=new_stamp_pos_y;

 

...

 

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!

The relevant code diff is here: https://github.com/tschak909/wow/pull/9/commits/132ce04659cbc8b07abae070263701af2acc3754

-Thom

Edited February 3, 2018 by tschak909

[CrazyChris]

Thanks for posting an updated ROM in this thread. I am

really looking forward to this game!

 

Chris