Home | Forums | What's new | Resources | |
Strategies for Reducing VRAM Usage? |
slinga - Sep 16, 2019 |
1 | 2 | Next> |
slinga | Sep 17, 2019 | |||
Thank you Xl2, that worked beautifully. I used your program here: 4 bpp sprite converter app.... I shrunk the sprites from ~8k each to ~1k. Transparencies worked as well. The only issue is my sprite is now upside down. I tried searching through sprites.c for all uses of SPR_ATTRIBUTE but it's always used with sprNoflip. Any advice? sprHflip, sprVflip, and sprHVflip are not defined by Jo Engine. |
slinga | Sep 18, 2019 | |||
I think I spoke too soon. When I have two overlapping sprites, the transparencies cause weirdness. Basically I see through one sprite straight to the background when I expect to see the other sprite underneath. |
XL2 | Sep 18, 2019 | |||||
Your background is with the VDP2? |
antime | Sep 18, 2019 | |||
Is the SPD bit set in your drawing commands? When it's set, pixels with a value of zero (palette index or RGB value) are not skipped, but are drawn into the frame buffer. |
XL2 | Sep 18, 2019 | |||
In fact can you show us a screenshot and in Yabause's debugger your sprite command? |
slinga | Sep 19, 2019 | |||
I'm attaching two screenshots: 1) 32bpp - calls jo_tga_loader() and jo_set_background_sprite for the background - jo_sprite_add_tga() and jo_sprite_draw3D2() for all of the sprites - this seemed to work well, except I was using a ton of VRAM - sprite transparencies work as I expect - the z parameter to jo_sprite_draw3D2() lets me order the sprites how I want 2) 4bpp - calls jo_tga_loader() and jo_set_background_sprite for the background - load_4bits_bin_image() and render_CLUT_sprite() from XL2's 4bpp convertor and sample program - VRAM usage dramatically lower - Sonic and the pipe are flipped upside down, Tails is right-side up. I can no longer use jo_sprite_enable_*_flip() to flip the sprites as I was before - transparencies work until I overlap them Thanks in advance. |
XL2 | Sep 19, 2019 | |||||
It was a while ago that I worked with Jo engine, but I think with my image converter it's expected that you use SGL functions directly. You could look at the exemples I made to make sure it's ok. I suspect that you simply forgot to flip the transparent pixel bit, so it draws transparent pixels with 0x0000 values instead of skipping them. Also look in Yabause sprite debugger to see if the sprite's orientation is ok. Look at the vdp1 manual for more info. |
slinga | Sep 19, 2019 | ||||||||||
I'm using the code directly from your 4bpp demo:
C:
The Yabause VDP1 Command List output for the Sonic image (renders upside-down):
The Yabause VDP1 Command List output for the Tails image (renders right-side up, but transparencies have issues like Sonic's):
I will spend some time reading the VDP1 manual. |
XL2 | Sep 19, 2019 | |||
Hmmm, I am surprised that the Tails image is upside down in Yabause's VDP1 debugger. Maybe it's an older version of my image converter :/ But you clearly here don't have the transparent pixel set, which explains your transparency problem. Just set it and it will show correctly. For the converter, cd 8 for 256 colors, cd 4 for 16 colors |
slinga | Sep 22, 2019 | ||||||||
Hi XL2, I believe I found the issue for the flipped sprites. When exporting my sprites to TGA some sprites were set to "Top Left" and others were set to "Bottom Left". Exporting all sprites to TGA as "Bottom left" fixed the alignment issue.
I'm stumped on how to do this. I was unable to find an "SPD" flag in SL_DEF.H. I did find and add a "CL_Trans" flag as follows:
C:
Some sort of half transparency is happening. I guess this is OK, but is there another set of flags I could be using? Thanks again. |
XL2 | Sep 24, 2019 | |||||
SPdis = transparency disable, should be SPenb (or something like that). And CL_Trans = half-transparency flag. I don't recommand that you use it. Also, for the scale, use 65535 instead of 65536, as it causes your sprites to be 1 pixel too big. |
slinga | Sep 24, 2019 | |||
Yes that was it. Thank you again for your help. My sprites appear to be rendering how I would expect. |
slinga | Oct 4, 2019 | |||
I'm struggling a bit with RAM/VRAM usage. Initially I thought I would be able to put all of my sprites in VRAM at once. Using Jo Engine, VDP1 appears to only have around ~400k of VRAM instead of 512k. Each pipe image I have is 128x112 or 7.2k. I have 55 pipe images so I'm using a total of ~396 k in just the pipe images. If I had access to 512k VRAM instead of ~400k I believe I could fit all of my sprites into VRAM, simplifying the game. I then attempted to do what Antime suggested by loading all of my images to main memory, and then stream them in and out of VRAM as needed. Unfortunately jo_malloc() only has around ~316k of RAM before it fails and returns NULL. I will look into jo_add_memory_zone(unsigned char *ptr, const unsigned int size_in_bytes) as LWRAM appears to be unused in XL2's example code. Just wondering if you guys had any thoughts. |
XL2 | Oct 4, 2019 | |||||
I always use lwram when I load stuff from discs, I doubt I did it in another way in these old demos. You also won't have 512 KB available because you need to leave space for draw commands, gouraud shading tables and lookup tables. 400-450 KB seems about right, depending on how much you allocate for each category. Offload everything you can to the VDP2 to save memory. And if your goal is to do the halfpipe from Sonic 2, doing the pipe in 3d should be easy and it should work well enough. |
slinga | Oct 4, 2019 | |||
Do you know if anything else is using LWRAM? If not I will go ahead and extend my jo_engine heap to use it as well. Regarding using 3d for the pipe, I like the idea but I believe it will be above my ability to get it working before the end of the contest (~6 weeks). |
1 | 2 | Next> |