It is currently Mon Dec 11, 2017 12:14 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 131 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 9  Next
Author Message
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Thu Jul 13, 2017 5:09 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
Thanks, but am using a special format here... One byte = a set of 9 tiles (a box) and any special functions it may have (4 of them) I'll just whip something up.

p.s. First dungeon drawn, and placed a few sprites in to double check sizing and proportion!

Image

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Thu Jul 13, 2017 10:03 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
I'm curious, how do you guys writing games in C keep score? WoW has a score max of 7 digits. which can't really be put nicely into a 16-bit quantity, but works well in a 24 or a 32 bit quantity..am curious if taking this pedestrian route is what's best here, or if somebody knows a more space efficient method?

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Thu Jul 13, 2017 10:09 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
A lot of the time it's sensible to just store a score in decimal, rather than as a binary number that you'd have to convert, i.e. just store the 7 digit score as 7 bytes (each value 0-10) and write a routine that will add points to it (carrying anything that overflows 10 to the next one).


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Fri Jul 14, 2017 8:39 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 262
Location: Central Illinois, USA
Also consider whether the lowest digits of the score are ever used. From a few google searches, it looks like the score increments by 100's. If that's the case, you don't need to store those last two digits.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sat Jul 15, 2017 4:17 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Quote:
Code:
ULDR TSWX
-------------
0000 0000
Having optimized cellular automata dealing with edges of squares, storing ULDR for every square is redundant; you only need to store DR, really.

But your choice will leave you with much easier collision checks, and possibility of one-way passthrough walls.


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sat Jul 15, 2017 4:47 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
I did consider storing only half of the data, but I liked the flexibility of storing everything.

Right now, am doing little experiments on sprite updating and vram updating (score etc). Things will slow down for a bit while I get the hang of the hardware.

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 12:27 am 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
I have placed the following disclaimer in my code:

Code:
/**************************************************
 * DISCLAIMER: This is not clean C code. It will  *
 * Never be clean C code. Everything here is done *
 * So that the result will either work, or fit    *
 * inside an NES, being that C was never an ideal *
 * language for the 6502. It is honestly a minor  *
 * miracle that CC65 exists and that it does as   *
 * well as it does. It is a testament to the      *
 * CC65 engineers to want to produce more than    *
 * a pidgin C compiler. Hats off to them, really. *
 * -Thom Cherryhomes 07/16/2017                   *
 **************************************************/


;)

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 1:41 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
Can somebody with an NTSC NES and a CRT monitor/tv please send pics of the three screens in this attached test ROM? am curious.

-Thom

Attachment:
wow_screentest.nes [24.02 KiB]
Downloaded 40 times


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 4:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
tschak909 wrote:
I have placed the following disclaimer in my code:

To be honest, it seems unnecessary to apologize for "unclean" code in a game.

A source code library should have clean code because the product is the code, and the users/customers are programmers.

With a game, though, the product is the game itself, and the customer is only a player. The cleanliness of the code is an internal implementation detail.

A clean code base is nice for the person who works with it, but it's normal to make at least a little mess in the process of developing and trying things. Cleanup takes time (and money), so it's pretty reasonable to not do it if the game is ready to ship.

Anyhow, I'm not saying you shouldn't strive to write clean code. It's well worth developing good code practices. Just I don't think there's any reason to feel shame for making a compromise in that respect.

tschak909 wrote:
Can somebody with an NTSC NES and a CRT monitor/tv please send pics of the three screens in this attached test ROM? am curious.

Several emulators have good NTSC emulation (often derived from Blargg's implementation), usually it's called a "filter". In FCEUX you can find an NTSC filter option under Config > Video, for example, but most emulators seem to have a similar option somewhere.

That emulation will show you pretty well what the NTSC signal does to fuzz up the picture.

The ways in which a CRT itself are different can't really be expressed well by taking a picture of a television. Mainly this has effects of overall brightness/gamma and saturation, and the "scanline" thing, but it doesn't really do much to degrade the image in ways that emulation of the NTSC signal alone won't.

(I don't currently have a CRT or I'd take a picture myself to show you, but in the meanwhile I'd recommend trying the emulated options.)


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 7:47 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
sigh. ... :)

(a) you missed my point on the disclaimer, but that's ok.

(b) I'm using blargg's filters in FCEUX. I'm just curious as to how the result frames on a tube.

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 8:14 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
Ah, well sorry for misinterpreting, in light of how I must now reinterpret it I hope I didn't come across as patronizing.


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 8:58 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
Not at all. :)

But I do have an interesting head scratcher... I'm constructing an update buffer for set_vram_update(), and thus far, it has been going swimmingly well, except the very last update directive (a vertical update at y=29), is causing a little flotsam of the same tile elsewhere on the screen, am I doing something stupid, or is this a bug? (I'm betting it's the former)

given the update code:
Code:
static unsigned char update_buffer[256]={
  /* Blue Door */
  MSB(NTADR_A(1,19))|NT_UPD_HORZ,LSB(NTADR_A(1,19)),
  3,
  0x74,0x63,0x75,
  MSB(NTADR_A(1,18))|NT_UPD_HORZ,LSB(NTADR_A(1,18)),
  3,
  0x76,0x64,0x64,
  /* Yellow Door */
  MSB(NTADR_A(27,19))|NT_UPD_HORZ,LSB(NTADR_A(27,19)),
  4,
  0x66,0x63,0x63,0x75,
  MSB(NTADR_A(27,18))|NT_UPD_HORZ,LSB(NTADR_A(27,18)),
  4,
  0x64,0x64,0x64,0x77,
  /* Blue Score */
  MSB(NTADR_A(2,25))|NT_UPD_HORZ,LSB(NTADR_A(2,25)),
  7,
  0x00,0x00,0x00,0x00,0x00,0x00,0x01,
  MSB(NTADR_A(2,26))|NT_UPD_HORZ,LSB(NTADR_A(2,26)),
  7,
  0x00,0x00,0x00,0x00,0x00,0x00,0x11,
  /* Yellow Score */
  MSB(NTADR_A(23,25))|NT_UPD_HORZ,LSB(NTADR_A(23,25)),
  7,
  0x00,0x00,0x00,0x00,0x00,0x00,0x01,
  MSB(NTADR_A(23,26))|NT_UPD_HORZ,LSB(NTADR_A(23,26)),
  7,
  0x00,0x00,0x00,0x00,0x00,0x00,0x11,
  /* Teleports */
  MSB(NTADR_A(1,7))|NT_UPD_VERT,LSB(NTADR_A(1,7)),
  3,
  0x73,0x73,0x73,
  /* [color=#FF0000]This part causes the red blips in the middle of the screen[/color] */
  MSB(NTADR_A(30,7))|NT_UPD_VERT,LSB(NTADR_A(30,7)),
  3,
  0x78,0x78,0x78,
  NT_UPD_EOF
};


I get:

Image

Notice the extra red bits where they're obviously not supposed to be? if I remove that last directive, the bar on the right goes away, and so does the mess...

wtf?

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 9:10 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
It's possible that ~68 bytes / 10 regions in the PPU update buffer might be too much to fit within the available vblank time with the library's NMI update handler. Maybe put a breakpoint on a write of $78 to $2007 (to catch those last 3 bytes going through) and check if it's happening within vblank, or too late. In FCEUX it'll say scanline 0 when it's too late (vblank runs in scanlines 241-260).

If the update write happens outside of vblank it will corrupt some stray part of the screen.

Aside from that, I don't see any obvious typos but I find the MSB(NTADR_A(1,19))|NT_UPD_HORZ,LSB(NTADR_A(1,19)), blocks really hard to visually read, so I could easily mistake those for correct. If you made two macros something like UPDATE_HORZ(1,19) and UPDATE_VERT(1,7) instead I wouldn't be as suspicious about misreading those?


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 10:35 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
Yup, looks like that's the problem. The question I have is, is it safe to call set_vram_update(); when the PPU is on?

I need to literally update different areas of the screen, depending on different events, score change, worrior doors opening, teleport happening, etc. If I can't call set_vram_update() while ppu is active, will I need to roll my own little queuing and scheduler code for this?

(sorry, if I am asking stupid questions, I am literally crash coursing myself through the NES hardware)

-Thom


Top
 Profile  
 
 Post subject: Re: WIP: Wizard of Wor
PostPosted: Sun Jul 16, 2017 10:52 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 98
So basically, I need to do the following sets of updates:

Scores: 28 tiles (two horiz rows of 7 tiles x 2)

teleports: 6 tiles (two vert rows of 3)

doors: 14 tiles (one set of two rows of 3 tiles, for the left, one set of two rows of 4 tiles for the right) (horizontal)

countdown: 4 tiles (2 sets of 2 rows) (each set in a different place)

lives: 4 tiles (same as countdown)

is this too much to handle in neslib's vram update list code all at once? Can I split this up?

-Thom

(irony of ironies, even here, away from the VCS, I am finding myself counting cycles) ;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 131 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 9  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group