GP2X Squidgesnes_0.37 Code Comments

[Daid]

Looking at the snippets people posted I see it uses some doubles? Without FPU that would be pretty slow, but wouldn't floats be faster?

Also is there a list of known bugs somewhere? (I couldn't find it)

 

[Squidge]

cxzuk: I've always had problems with gprof - it always seems to generate the file, but it's empty

 

[cxzuk]

Hey dood,

Empty? Hmmm.. Could be due to ARM arch? - If someone could send me a gmon.out file ill have a look, (unless its 0bytes "empty")...

Daid:
does the gp2x not have a FPU? - If so, give this a try

change the (from memory, i think its in gp2xmain.c?)...

#include "dsp1emu.c"

to

#include "dsp1emu_fixed.c"

this should then use int32's instead of floats.

Mike

 

[Mudi]

How expensive is the '%' operator on the GP2X?
Also, can we use gprof for GP2X executables?

IIRC it's quite expensive, just as expensive as a divide I think.

 

[yaustar]

IIRC it's quite expensive, just as expensive as a divide I think.

In that case, something very minor: gfx.cpp line 618

	if (++IPPU.FrameCount % Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}

could (?) be changed to

	if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}

 

[cxzuk]

IIRC it's quite expensive, just as expensive as a divide I think.

In that case, something very minor: gfx.cpp line 618

	if (++IPPU.FrameCount % Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}

could (?) be changed to

	if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}

lol!!!!!! ... ok read it ... It says...

Is the remainder of IPPU.FrameCount / ROMFramesPerSecond = 0? ... so if ROMFramesPerSecond = 2... FrameCount can be any mult of 2.. so 2,4,6....

Now heres the thing... IF it = {2,4,6,...} then set FrameCount = 0!! so it will only EVER reach "2"

basically, my point is, With that snippet, you should be able to change it to,

if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)

Might have to check to see if other factor's come into play.. but that should work with the code above. =)

Mike

 

[Squidge]

I mean zero bytes empty, yes.

 

[yaustar]

Slightly OT, what would be faster on an ARM chip:

// a bitwise operation and comparing to 0
if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)

or

// comparing to a non 0 value?
if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)

 

[cxzuk]

If compare to 0 is faster..

if (--IPPU.FrameCount == 0)
{
	IPPU.FrameCount = Memory.ROMFramesPerSecond;
}

=)

Mike

Slightly OT, what would be faster on an ARM chip:

// a bitwise operation and comparing to 0
if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)

or

// comparing to a non 0 value?
if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)

I think we should start a page on the wiki with coding tips, such as whats faster.

 

[yaustar]

If compare to 0 is faster..

if (--IPPU.FrameCount == 0)
{
	IPPU.FrameCount = Memory.ROMFramesPerSecond;
}

=)

Mike
I think we should start a page on the wiki with coding tips, such as whats faster.

http://www.arm.com/pdfs/DAI0034A_efficient_c.pdf
Page 11, Section 5.2

 

[cxzuk]

Hi all,

Looking in tile.cpp.

it seems to have lots of functions like..

__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
   		uint16 *Screen = (uint16 *) GFX.S + Offset;
   		
		  Screen += 7 * 320;

   		#define FN(N) \
   			if (!(solid&(1<<(7-N)))) *Screen = *Pixels; \
   			Screen -= 320; Pixels++;
   		FN(0)
   		FN(1)
   		FN(2)
   		FN(3)
   		FN(4)
   		FN(5)
   		FN(6)
   		FN(7)   		
   		#undef FN 
}

surely defining code, running it 7 times, then undefining it must be slower than a normal loop?

  ...
// create lookup[x] table (1<<(7-x))
uint8 FN_lookup[7] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01};
  ...

__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
  uint16 *Screen = (uint16 *) GFX.S + Offset;
   		
  Screen += 7 * 320;

  for(int c = 7; c != 0; c--) {
	if (!(solid & FN_lookup[c])) *Screen = *Pixels;
	Screen-=320; Pixels++;
  }
}

am i wrong?

Mike

 

[yaustar]

I am afraid so. #define and #undef are preprocessors and are done at before compile time. It won't matter at runtime. What it comes out as before the compiler sees it:

__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
		   uint16 *Screen = (uint16 *) GFX.S + Offset;
		   
		  Screen += 7 * 320;

				 if (!(solid&(1<<(7-0)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-1)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-2)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-3)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-4)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-5)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-6)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-7)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
}

In which case your code will be slower as the orignal code unrolls the loop whereas yours is in a for loop with one extra variable and two extra operations per loop.

 

[Mudi]

Actually it's exactly the same, because the makefile I use with this has a -funroll-loops.

 

[yaustar]

hmm.. didn't know about that flag. How useful has it been?

 

[Mudi]

Well, it pretty much unrolls any constant-iteration loops. That's about all there is to it.

 

[Squidge]

In which case your code will be slower as the orignal code unrolls the loop whereas yours is in a for loop with one extra variable and two extra operations per loop.

Not only that, but because you are branching, your affecting the prefetch and causing it to be emptied and refilled at the new location.

 

[cxzuk]

Hi all,

Ive read over the code, and its pretty basic algorithms and coding. Pretty hard to optimise.

Someone mentioned rewriting the gpu.

I would prolly say a complete start again, converting over the current code into GP2x optimized code is prolly the best way to go, and replacing as much as pos with ASM. (such as the sound core mentioned).

I just think the current code is too full of other useless code.

What do u think?

Mike

 

[Squidge]

I agree, but rewriting the GPU is a huge task.

 

[cxzuk]

I agree, but rewriting the GPU is a huge task.

I would be willing to help, but i have no real idea as to how it works. And im sure theres lots of others that would help.

If it was to be done, it would more than likely need a "todo" list, or a project leader.. or both. If you could provide that im sure the work would be done much quicker.

Mike

 

[Emu&Co]

One step that might help to improve the speed is using the new snes9x 1.50 Source and replace the shared stuff. What do you think?