WIP: Wizard of Wor
Moderator: Moderators
Re: WIP: Wizard of Wor
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!
-Thom
p.s. First dungeon drawn, and placed a few sprites in to double check sizing and proportion!
-Thom
Re: WIP: Wizard of Wor
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
-Thom
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: WIP: Wizard of Wor
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).
Re: WIP: Wizard of Wor
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
Re: WIP: Wizard of Wor
Having optimized cellular automata dealing with edges of squares, storing ULDR for every square is redundant; you only need to store DR, really.Code: Select all
ULDR TSWX ------------- 0000 0000
But your choice will leave you with much easier collision checks, and possibility of one-way passthrough walls.
Re: WIP: Wizard of Wor
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
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
Re: WIP: Wizard of Wor
I have placed the following disclaimer in my code:
-Thom
Code: Select all
/**************************************************
* 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
Re: WIP: Wizard of Wor
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
-Thom
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: WIP: Wizard of Wor
To be honest, it seems unnecessary to apologize for "unclean" code in a game.tschak909 wrote:I have placed the following disclaimer in my code:
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.
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.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.
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.)
Re: WIP: Wizard of Wor
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
(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
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: WIP: Wizard of Wor
Ah, well sorry for misinterpreting, in light of how I must now reinterpret it I hope I didn't come across as patronizing.
Re: WIP: Wizard of Wor
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:
I get:
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
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: Select all
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
};
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
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: WIP: Wizard of Wor
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?
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?
Re: WIP: Wizard of Wor
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
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
Re: WIP: Wizard of Wor
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)
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)