Starfield Demo

I was thinking of doing a demo of the star-field particle effect that I have coded and putting up the source in the demo section of wiibrew. worth it? or is it too simple for a demo?

I've finished the app, and source is here; [wiibrew.org]



Edited 1 time(s). Last edit at 09/22/2011 08:57PM by owen.

Go for it, could be a good subject for a mass peer review!

Took a couple hours and whipped the demo together; [wiibrew.org]
The source is there too so you can chew it to bits, lol. It is in C with bits of GRRLIB. It starts running at 30 fps if you increase the stars to 130,000. In my game I only use at most 400 but its a demo so I push the limits. It could possibly be used for rain too with a few tweaks.

Originally the code was written like this (not exact);

GRRLIB_ObjectView( 0, 0,-3000, x_rotation,y_rotation,0, box,box,box);
			
for(i=0;i<star_limit;i++) {  //vertical lines
	//draw a signle point using a line, or a dot if you want
	GX_Begin(GX_LINES, GX_VTXFMT0, 2); 	
		GX_Position3f32(); GX_Color1u32(col);
		GX_Position3f32(); GX_Color1u32(col);			
	GX_End();				
}

When I do this I could draw up to 130,000 lines before the frame rate would drop to 30 fps.

Now I've changed the code to be like this (not exact);

GRRLIB_ObjectView( 0, 0,-3000, x_rotation,y_rotation,0, box,box,box);

	GX_Begin(GX_LINES, GX_VTXFMT0, star_limit*2); 	
		for(i=0;i<star_limit;i++) {  //vertical lines
			//draw a signle point using a line, or a dot if you want
			GX_Position3f32(); GX_Color1u32(col);
			GX_Position3f32(); GX_Color1u32(col);	
		}
	GX_End();

However when I do this I noticed that if starlimit is greater than 32,000 then the GX engine would crash/freeze. Seems that there is a limit to how many lines can be in a single GX Block (64,000).

So now I'm using this last technique since it may be faster than the previous method, though I can't put as many stars on the screen. But who really needs 180,000 stars?

Owen, this is just for information only I know you have moved on, I think this one ups the amount (If someone could confirm that without flaming), no idea if there is a limit on this (I would not think so) apart from memory limits.
( or use a calculation to batch it into smaller groups that fit )

#define DEFAULT_GX_FIFO_SIZE ( (4*256) * ONE_KILOBYTE) // my amount bigger than I need

	if (m_gp_fifo==NULL)
	{
		m_gp_fifo = (u32*)memalign(32, GXFifoBufferSize);
		memset(m_gp_fifo, 0, GXFifoBufferSize);
		GX_Init(m_gp_fifo, GXFifoBufferSize);

		printf ("using %d for GX Fifo",GXFifoBufferSize);
	}

Edited 1 time(s). Last edit at 09/22/2011 08:26PM by Titmouse.

@Titmouse I think 64,000 is fine. Anybody needing more than that should probably not be coding on the wii. :p

Owen, I just took peek at your star field code – looks good.
If you ever needed a speed boost you could pre calculate a large star field in a traveling loop (pre calculated scene), and then move the camera through it, this world remove the need to update the star movement – it would require a bit of memory and the rest of your world (not needed for demo) would need to fit in with it. Using GX_CallDispList you would probably get away without the need to break it down in areas, just drawing the whole thing and letting the GX take the hit for anything outside camera view.

However your method does give infinite 100% random effect which the above can’t.

Must say top points for the Grow idea, would never occur to me to do it that way, very useful since the same value can be checked to end the star which really optimised the code, nice.

(Take another look at your code, you've left in a few unneeded functions in by mistake I spotted when using notepad++ double click highlight)

The starfield is really none interactive, so putting it in a world would not help much. It depends on what you doing really. The flaw in this starfield effect is that if you look at it from the wrong angle the effect is lost. Also if you put too many stars in it you can see the box that the stars live inside. So this trick could not be used for a freespace game. This effect is only good for scrolling shooters, intros and title screens.

Yeah, I left a couple functions in there because I was not sure what I was going to need when I started deleting stuff from NewoShooter. I even thought about including my menu code but I did not want to complicate what should be a basic effect demo. I was even hesitant to leave my button checking code in there but I have gotten so accustomed to using it that I can't live without it, lol.

Grow idea? what is that? Oh I See what you talking about. For another effect I have a direction[3] value which tells me if the star is moving towards 1 or towards -1. which Now that I think about it. What if I do this for the reset position check;

	if(  (stardust[i][0] + stardust[i][1] + stardust[i][2]) ==0  ) {  //reset to random position
			stardust[i][0]=(randnum(100)-50)*d;
			stardust[i][1]=(randnum(100)-50)*d;
			stardust[i][2]=(randnum(100)-50)*d;
	}

Should be faster than the 3 boolean checks. No?

Looks like your only changing Z pos, stardust[][2]
So just test Z pos and just zero Z pos too. i.e. just use if ( stardust[i][2]==0 ) { ...

stardust[i][2]+=d/2, think divides are slow use multiply, i.e. stardust[i][2]+=d*0.5f;
The opimiser may do that anyway.

You are using lots stack space, also not sure why you have use [4] (just read your note about direction, but its not used in the demo), I tend to use dynamic mem.
float stardust[180000][4] <----- x,y,z = 3

For more performance you could use

//set once per loop
float* Star = stardust[i];  // &stardust[i][0];  will do the same thing

then do things like

GX_Position3f32(Star[0],Star[1],Star[2]);   // again optimiser my do this for you

Since you access them lots.
Then you could (struct is better) do this.

#define X (0) ; #define Y (1) ; #define Z (2) ; 
above becomes GX_Position3f32(Star[X],Star[Y],Star[Z]);

Edited 1 time(s). Last edit at 09/22/2011 11:02PM by Titmouse.

Yeah that 180000 should really be 32000 since its one star for each point. I will change that later. And I'll remove that extra directional index as well.

As for the dynamic storage, I often reuse the array for different effects (only one effect can be active at a time) so I always keep a tight hold on everything that is in the system at any point in time. No deallocation or reallocation of memory, everything is in a fixed space.

Yeah that could be a struct. would be easier to extend and read too.

Got some videos from wii64 [www.youtube.com] and Cid2Mizard [www.youtube.com]

You can see in the second video when he puts more than 4000 stars on the stage you can begin to see the cube. This can be avoided by increasing the size of the box value (which is hardcoded to 3000).

At certain angles you can pull off a rain effect. I imagine that if you replace the draw line with a draw texture you could pull off the effects similar to what Goldeneye 007 Wii use [www.youtube.com]

I really like this effect; I also like the square effect when you up the stars to silly amounts. It’s a very slick Algorithm.

If you’re open for a bit of constructive criticism, don’t want to hit you with all this on the first post.
This is a difficult thing to do correctly - But always try to keep your logic away from your display code. (demo or not)
I was going to write all about why this is good since it reduces complexity – but I have a feeling you’re not going to care, but do have a think about it as things like paused game need one logic point; this is just the tip of the iceberg.
Break the code into more component parts, say for draw_stardust(). This would allow you to remove unnecessary logic, if (i % 2 == 0) x2, passing a parameters to a new func that was the body of the loop. Basically this function can be refactored, which may or maynot give a boost but thats not what refactoring is about.
(As it stands you only need one if (i%2==0), move the two parts together – you could also use bitwise logic instead of the % but the optimiser will probably pick up on that)
How come you use ‘&’ in non bitwise logic?

I'm always up for constructive criticism! The difference between & and && isn't considered. I never understood bitwise logic in college most of the time I'm just checking if a set if boolean expressions are either true or false.

The square effect is a more of a bug than anything else. I imagine it would be interesting if you made the cube a elongated rectangle. Or maybe force a hole in the

How I handle the pause game issue is by writing the functions in a way such that the display code is above the logic code in a kinda fall through technique. Any function that needs to know whether the game is paused or not can check the "stage_paused" variable. Most times I pass the variable to the function. Its very procedural as opposed to a OOP model which is used for more complicated stuff.
There is a line in the demo source that says;

//if(stage_paused) continue;  //freeze the movement if the game is paused

This line skips the movement code and so operates in a "draw only" state, freezing the stars in place.

I keep simple things simple. I don't add these effects to frameworks or render pools. More complex effects would require re-factoring, especially if they have costly activities like collision detection and button checking. This star-field effect however is non-interactive and only moves when it is displayed making it self contained and easy to manage. Refactoring this would make it highly complex, plus you would need a render pool, which would lead to other problems like dynamic lists and memory management.

I must say I kind of agree with the way you work, gives results.

As for '&&' and '&' - You tend to use '&' for bit logic

"A single ampersand always evaluates both arguments (a & b) whereas the double ampersand will only evaluate the second argument if the first argument is true (a && b)."

If (a & b & c & d) // everything is always evaluated, kind of like the way a + b + c + d works as you need the result of the whole thing back

if (a && b && c && d) // if a&&b are false ,the ‘c’ language knows there is not point going on and looking at the rest

This bit is very important.
if ((Pointer!=NULL) & (Pointer->thing==123)) //crash
if ((Pointer!=NULL) && (Pointer->thing==123)) //ok

Yeah I understand. I'm definitely always doing option 1. I never do option 2 because its pretty reckless, I always break it into 2 if statements once there is a possiblity that the object could be null.

Not sure if I get you, are saying you never you use '&&', and yes breaking the last post example into two line is what I do, those one-liners give me the willies.

if ((x < Rx + Rect.w) && (x >= Rx ) && (y < Ry + Rect.h) && (y >= Ry ))  
// standard way, (x < Rx + Rect.w) == false then it knows the answer

if ((x < Rx + Rect.w) & (x >= Rx ) & (y < Ry + Rect.h) & (y >= Ry )) 
 // works but is very odd thing to do and can be slower to execute (evaluates the lot unlike &&)

Yes, exactly that.

Ok it’s there if you ever need it, looks like it’s called ‘Short-circuit evaluation’.
(Can help things like box collision detection.)

http://en.wikipedia.org/wiki/Short-circuit_evaluation

cool, Its not something I plan to ever use though.

Most cases if I need something Iike that I would use separate IF statements.



Edited 1 time(s). Last edit at 04/06/2012 10:43PM by owen.