It is currently Mon Jul 24, 2017 11:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Thu Jul 13, 2017 1:04 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18667
Location: NE Indiana, USA (NTSC)
Would using a bucket sort, maintaining a display list for each texture and adding each quad to the appropriate texture, run faster than qsort? You might need two passes over the tilemap, one to count tiles using each texture and one to actually build the display lists.


Top
 Profile  
 
PostPosted: Fri Jul 14, 2017 1:08 pm 
Offline
User avatar

Joined: Thu May 25, 2017 7:27 am
Posts: 15
tepples wrote:
Would using a bucket sort, maintaining a display list for each texture and adding each quad to the appropriate texture, run faster than qsort? You might need two passes over the tilemap, one to count tiles using each texture and one to actually build the display lists.


Dunno, how much memory would take the bucket sort?

For the function i did 2 codes, the first one seems to run faster than qsort on layers like that:
Code:
// tile size: (32x32)
// 10 x 4
static uint16_t map2 [40] =
{
   106,107,106,107,0,106,107,106,107,0,
   108,109,108,109,0,108,109,108,109,0,
   110,0,110,0,0,110,0,110,0,0,
   111,0,111,0,0,111,0,111,0,0
};


Textures from 106 to 111 in consecutive way with not so many calls (0 is ignored), however the difference is 1 or 2fps.

Code:
void texture_list(int opt)
{
   int zx,zy;

   // optimized for layers
   if (opt==0)
   {   
      // check
      if (min_tex>max_tex) { min_tex=max_tex; }
   
      for(zx=min_tex;zx<max_tex+1;zx++)
      {   
         // load texture into TMEM
         if (last_texture!=zx)
         {
            rdp_load_texture(graph[zx]);
            last_texture=zx;
         }   
         
         for(zy=0;zy<num_tex;zy++)
         {   
            if (zx==tex_tile[zy].tex)
            {   
               // draw      
               rdp_draw_sprite(tex_tile[zy].x,tex_tile[zy].y,0);   
            }   
         }
      }
      
   }   
   else // optimized for main scroll
   {   
      
      qsort( tex_tile, num_tex, sizeof(tex_tile[0]), compare );
      
      // display
      for(zx=0;zx<num_tex;zx++)
      {   
   
         // load texture into TMEM
         if (last_texture!=tex_tile[zx].tex)
         {
            rdp_load_texture(graph[tex_tile[zx].tex]);
            last_texture=tex_tile[zx].tex;
         }
                           
         // draw      
         rdp_draw_sprite(tex_tile[zx].x,tex_tile[zx].y,0);      
         
      }
      
   }   

   // reset values
   min_tex=9999;
   max_tex=0;
   num_tex=0;
   texture_sort=0;
}


Last edited by BMBx64 on Fri Jul 14, 2017 7:40 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jul 14, 2017 2:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18667
Location: NE Indiana, USA (NTSC)
BMBx64 wrote:
tepples wrote:
Would using a bucket sort, maintaining a display list for each texture and adding each quad to the appropriate texture, run faster than qsort? You might need two passes over the tilemap, one to count tiles using each texture and one to actually build the display lists.

Dunno, how much memory would take the bucket sort?

Unlike question inversion in some other languages, question inversion in English moves only the tensed verb: the "would" in "would take". This way, the listener can still tell subject and object apart: "Weena would eat..." becomes "What would Weena eat?" not "What would eat Weena?", which sounds a bit more cannibalistic to an English speaker. With that out of the way:

"how much memory would the bucket sort take?"
Enough to hold all the display list entries, plus as many pointers as there are textures. Each pointer points to the display list associated with a particular texture. For example, if there can be up to 300 tiles or portions thereof with four textures and 320 tiles on the screen (assuming a 304x224 canvas with partial tiles), you'd need four display list pointers plus enough memory for 300 quads.

How did I arrive at 300 tiles? Say you're drawing 16x16-pixel tiles to a 304x224-pixel canvas, with 8 pixels of black border on each side. This is the typical canvas size for Neo Geo and Nintendo 64 games so that they don't have to spend GPU time rendering so much of the part of the picture hidden by overscan. This is 14 rows of 19 tiles each. But when scrolling a tilemap, you need an additional row and column to account for tiles being half scrolled off, so 15 rows of 20 tiles, or 300 in all.


Top
 Profile  
 
PostPosted: Sun Jul 23, 2017 5:05 am 
Offline
User avatar

Joined: Thu May 25, 2017 7:27 am
Posts: 15
ALPHA BLENDING TEST
Small test that shows 32 levels of transparency in 1cycle mode (16bit mode / RDP).
Image

CONTROLS
A - Flip Sprite
Z - Enable/Disable Additive blending
L/R - Alpha control
Joy - Scroll
C buttons - X / Y Scale (zoom)

DOWNLOAD
https://mega.nz/#!YtwGUbJC!y1zx0efruI_ezXkJQnm4csosFxDDxP5qo7v9bKtu5J4

New functions added to libdragon (i may post the new lib if anyone interested):

fixes x_scale, RGB scale support, no alpha support
Code:
void rdp_texture_1cycle( void );

same, with bilinear filter when zoomed
Code:
void rdp_texture_filter( void );

like 1cycle but enables alpha support
Code:
void rdp_alpha_blending( void );

like 1cycle with alpha support plus additive
Code:
void rdp_additive_blending( void );

controls alpha blending and rgb scale (tint)
Code:
void rdp_rgba_scale(uint8_t _r, uint8_t _g, uint8_t _b, uint8_t _alpha);


- Add have no color cap and needs to be controlled with rgba_scale.
- RDP commands used: Set Other Modes, Color Combiner, Set Prim Color.
- Small fixes on libdragon.

Thanks Krom for explaining to me how the RDP works.


Top
 Profile  
 
PostPosted: Sun Jul 23, 2017 9:11 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5920
Location: Seattle
BMBx64 wrote:
Thanks Krom for explaining to me how the RDP works.
I found a post on ElOtroLado.net containing your username and their username ... is that basically the same information?


Top
 Profile  
 
PostPosted: Sun Jul 23, 2017 10:04 am 
Offline
User avatar

Joined: Thu May 25, 2017 7:27 am
Posts: 15
This one?
https://www.elotrolado.net/hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497

Yeah, similar info regarding libdragon, there is a bit of trivia and analysis of comercial games as well (framerate, debug, wireframes, poly count, etc).

Krom ASM examples can be found here:
https://github.com/PeterLemon/N64


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group