It is currently Fri Apr 20, 2018 9:47 am

 All times are UTC - 7 hours

 Page 4 of 12 [ 166 posts ] Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 12  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: WIP: Wizard of WorPosted: Thu Jul 13, 2017 5:09 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

Top

 Post subject: Re: WIP: Wizard of WorPosted: Thu Jul 13, 2017 10:03 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Post subject: Re: WIP: Wizard of WorPosted: Thu Jul 13, 2017 10:09 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6202
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

 Post subject: Re: WIP: Wizard of WorPosted: Fri Jul 14, 2017 8:39 am

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 370
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

 Post subject: Re: WIP: Wizard of WorPosted: Sat Jul 15, 2017 4:17 pm

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 958
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

 Post subject: Re: WIP: Wizard of WorPosted: Sat Jul 15, 2017 4:47 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 12:27 am

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 1:41 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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]

Top

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 4:47 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6202
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 7:47 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 8:14 pm

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

Top

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 8:58 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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 */
3,
0x74,0x63,0x75,
3,
0x76,0x64,0x64,
/* Yellow Door */
4,
0x66,0x63,0x63,0x75,
4,
0x64,0x64,0x64,0x77,
/* Blue Score */
7,
0x00,0x00,0x00,0x00,0x00,0x00,0x01,
7,
0x00,0x00,0x00,0x00,0x00,0x00,0x11,
/* Yellow Score */
7,
0x00,0x00,0x00,0x00,0x00,0x00,0x01,
7,
0x00,0x00,0x00,0x00,0x00,0x00,0x11,
/* Teleports */
3,
0x73,0x73,0x73,
/* [color=#FF0000]This part causes the red blips in the middle of the screen[/color] */
3,
0x78,0x78,0x78,
NT_UPD_EOF
};

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

Top

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 9:10 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6202
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 10:35 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Post subject: Re: WIP: Wizard of WorPosted: Sun Jul 16, 2017 10:52 pm

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 123
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

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 4 of 12 [ 166 posts ] Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 12  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 5 guests

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

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki