TEST 2: BIGGER EXPLOSIONSInstead of 2KB explosions these are around 122x96 (22KB), so they are split in several pieces to fit the 4KB cache (i dont use stride function on libdragon, is slower than manage single textures), i wonder if there is an easy way to use 4 or 8bit textures with libdragon (they are limited to 16bit-32bit).

USES- Can be used on a paint program (or those racing games with a menu to select a color for a car)- Can be used as hidden collision map (since it reads the current buffer)- Allows users to create new functions- Can transform color into data to copy block areas or do special effects (VERY SLOW)

TESTA color table is written on the buffer, the mouse reads the color from the buffer and shows it on the rectangle.

16bit value to RGB conversion (this conversion is not necessary, but just in case)

---I could provide the source code of these examples, but probably the level skills on this board are better than me.

Right now im trying to figure how to add hardware flip to the sprites, it is possible by changing the order of the loading or using mirror S or T coords when drawing, but this code brings me headaches, i simply don't know where to start:

(the code is slightly modified from the source, i have removed texture slots)

This second one is used for drawing the texture once is loaded into tmem, so either when loading could be mirrored or now, i have added if ( tx < -cache.width ) { return; }, prevents system to hang when a sprite is out of screen from the left (it seems to be the only exception).

Also, I don't understand how the second explosion demo has such worse performance than the first. Are you drawing all the pieces of an explosion with the same graphic before swapping out the texture in the texture cache? This should improve GPU performance, put then you'd also have to use the hardware z-buffer when drawing the explosion pieces instead of just sorting the order they are drawn with the CPU, which may negate the performance increase from changing the texture cache less often.

I actually did Google libdragon, but I didn't really know what I was looking at. Is it a full game engine, or routines that could be used to make one? Seems pretty limited if it apparently can't support 4bpp or 8bpp textures, which shouldn't have been any harder to implement than 16bpp or 24bpp or 32bpp textures other than a palette also needs to be uploaded. (Also to the texture cache?)

...but then you'd also have to use the hardware z-buffer when drawing the explosion pieces instead of just sorting the order they are drawn with the CPU, which may negate the performance increase from changing the texture cache less often.

I don't know the first thing about N64 development, but isn't the whole point of a hardware Z-buffer that it's faster than sorting polys on the CPU?

Using a depth buffer incurs an extra memory read per pixel and write per drawn pixel, and it doesn't work for translucent objects. I don't know enough about the Nintendo 64's memory controller to know under what exact conditions the tradeoff is favorable. It was common on the PlayStation to use a bucket sort based on the Z coordinate of the centroid, which is fairly fast provided there are no pathological cases of large triangles close together.

isn't the whole point of a hardware Z-buffer that it's faster than sorting polys on the CPU?

Yes. However, using the hardware Z-buffer is slower for the GPU. If you are not changing out the texture cache for identical pieces in this case, you have to use the hardware Z-buffer, because you won't be able to sort the pieces of the explosions on a per pixel level by the CPU like the hardware Z-buffer will. You can avoid using the hardware Z-buffer by writing entire explosions in order, but then you have to change out the texture cache for every piece being drawn.

Yeah, I get it - I guess I'm just surprised using the Z-buffer is so much slower that it might be better to do CPU sorting & constantly trash the texture cache when you're not even pushing the GPU that hard (5000 unshaded unlit triangles per second). And that's not an "I'm surprised because that sounds unlikely and think you're wrong" kind of surprised, but a genuine, "woah, the N64's Z-buffer must be terrible" kind of surprised.

The SOTN demo worked really well, music played until it got to BGM 12, then it stalled the system. Had to reset.

Tried again, skipping tracks to get the BGM 12 which now worked, but when I skipped to BGM 13 it stalled again.

This is testing on an Everdrive64.

Thanks , not sure why it crashes, do you use expansion pak? I have PAL N64 with expansion and works fine forcing PAL or NTSC modes on Everdrive 2.5.

However i know fopen/fclose have a memory leak, once the 100th file is open the next ones will fail (no handles), this can be "fixed" by using (dfs_open and dfs_close variant), i have to look at it, audio specially has been hard on N64 so far.

Also, I don't understand how the second explosion demo has such worse performance than the first. Are you drawing all the pieces of an explosion with the same graphic before swapping out the texture in the texture cache? This should improve GPU performance, put then you'd also have to use the hardware z-buffer when drawing the explosion pieces instead of just sorting the order they are drawn with the CPU, which may negate the performance increase from changing the texture cache less often.

I wanted to check how goes the performance when textures are loaded without strategy, just to imagine worst scenarios, the sorting is done by the order in the program, a loop from 0 to max number of explosions, i don't know if Z-buffer is available for 2D rectangles.

--

For 8bit palettes, the low 2KB of the TMEM are filled with data, but the higher 2KB needs the color table lookup, then there are different formats, the grayscale ones works different i think, you can take more TMEM and set the color on the vertex.

I may be interested specially on 4bit palette support (MD,SNES,etc), but i hope to fix all the basic things, like flip a sprite if anyone can help a bit with the rdp.c code i can do all kind of tests.

--

I forgot this one..

TEST: LAYERSSmall tiled scroll that manages unlimited layers (they impact performance at some point), some features:- Layers can have a custom number of rows and columns- Different tile sizes in each layer separately (ex: main scroll layer 32x32, background layer 64x32)- Layers can be set to repeat horizontally or vertically.

This pic shows 8 full screen layers (320x240x16), each one with unique texture:

You know, I was going to post some thoughts I had on these demos and ideas on how to improve them, but I realized I really have no clue how exactly the N64 really works. I think the GPU is split into two parts, the RSP and the RDP, with the RSP being programmable and running the non-programmable RDP. Each one has 4KB of ram, with the RSP's ram holding instruction data and the RDP's ram holding texture data. What I really want to know, is how is the data changed? Is it by DMA initiated by the CPU, because if so, it seems the CPU would be doing nothing but waiting for the GPU to be done with its current task (like writing to the SPC700 on the SNES), unless the GPU can actually generate an interrupt.

Instead of reverse texture on the load i though it was more wise when drawing, there could be plenty of uses without reload such as axial symmetry.

I had to debug first how it works, the textures seems to be power of two sizes, for example mario texture is 16x31 and its rounded to 16x32, s and t coords have to be set accordingly to avoid garbage.

The performance seems to be about the same when setting MIRROR_ENABLED on the RDP (for hardware flip) so i removed some flags from rdp_load, this function previously used to be:rdp_load_texture (uint32_t texslot, uint32_t texloc, mirror_t mirror_enabled, sprite_t *sprite)

Now its just the texture call (which is faster):rdp_load_texture ( sprite_t *sprite )

Who is online

Users browsing this forum: No registered users and 1 guest

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