Currently giving myself a crash course in vram_set_update() and the different update vram functions in neslib..goal is to re-draw the dungeon in code, and work out a reasonably quick and compact data structure for the dungeon...now that I have a reasonably good idea of how the tiles in the nametable are to be laid out.

Took a first crack at the dungeon rendering code, which renders from an array of data in the following format

Code:

ULDR TSWX-------------0000 0000

Where ULDR is Up, Down Left, Right which sides of the box are to be open, T indicates a teleport wall, S is an enemy spawn point, and W is a Wizard spawn point. Worluk is special as he always appears at one door, and traverses toward the other.

The first pass of the code is inefficient, and I will refine it as I think it through further, but the meat of it is:

I'd get rid of the *3's. Using "*" includes extra runtime code plus is slow. You can do the X*3 as (X+(X<<1)) for example. You can also precalculate the offsets. offsX, offsY are unsigned char. addr is unsigned int.

// Down a row in the nametable addr+=32; vram_adr (addr); // Here: 'vram_put's for the second row.

// Down a row in the nametable addr+=32; vram_adr (addr); // Here: 'vram_put's for the third row.

// Next tile: offsX += 3; } // Next row of tiles offsY += 3; }

That way you calculate the base address, in the most simple way (just a shift and an addition, which is what NTADR_A does), just once per tile, simplifying your code, thus saving both bytes and cycles.

I'd get rid of the *3's. Using "*" includes extra runtime code plus is slow. You can do the X*3 as (X+(X<<1)) for example.

The compiler should be doing this shift conversion for you. If you can prove that it isn't, then either A. something in your code is of the wrong type or B. you need to file an issue.

Quote:

You can also precalculate the offsets. offsX, offsY are unsigned char. addr is unsigned int.

Code:

// ... // Next tile: offsX += 3;

This appears to be related to strength reduction, where you can update addresses with a simpler operation based on the recursion that xtimes3[x + 1] = xtimes3[x] + 3. So instead of multiplying by 3 for each cell, add 3 to the destination VRAM address after drawing each cell.

All valid points, indeed. I will go through and refine the algorithm as I can.

A note, I am not familiar with CC65 internals. To be blunt, the common wisdom BITD was that the 6502 COULDN'T do a decent C without EMULATING ANOTHER PROCESSOR (p-system, and most 6502 C's that I used literally modelled an 8080, so CC65 to me seems like something of a minor miracle.), so I am not sure WHAT compiler optimizations are actually taking place yet (I need to sit down and look at the outputted source code.

So... doing (x<<1)+x is slightly faster, I think, but there's a lot of encumbering inefficiencies anyway (stack temporaries, promotion to integer), so the difference is kind of pointless unless you want to write the multiply directly in assembly.

I think you're actually better off with x*3 just because it will produce smaller code (and code size tends to be a serious problem with CC65).

I've been working for years with a fairly old version of z88dk, so I have the (bad?) habit of not trusting the compiler at all. I also have the bad habit of not checking, which I should start doing, as I was avoiding structs in cc65 'cause I mistakenly thought that they generated worse code when accessing the members than using plain variables. My bad.

In this case, the *3 would indeed be better 'cause this is not a time critical task, so saving bytes is a priority.

I stand, thus, corrected

tepples wrote:

This appears to be related to strength reduction, where you can update addresses with a simpler operation based on the recursion that xtimes3[x + 1] = xtimes3[x] + 3. So instead of multiplying by 3 for each cell, add 3 to the destination VRAM address after drawing each cell.

I do this all the time, when appliable. It saves me tons of headaches, at least for my own mindset.

Who is online

Users browsing this forum: No registered users and 2 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