allegro 5 c++ project works with code::blocks - stars
altalena

Sorry if I'm not supposed to post twice about the same program, but the old thread got locked. I've added comments and cleaned up the code to make it work as a c++ Code::Blocks project for Allegro 5.0.4. I've attached an executable, a font, and source code. Hope people have more success running it than the last version.

Edit: I added screenshots of the new menu and three frames of moving towards the centre of the star cluster.

Edgar Reynaldo

Seems to render fairly slow on my Gateway M1670 with an integrated ATI Radeon X1270. Is it CPU or GPU bound?

The mouse control is either unintuitive or else just too sensitive. Moving up and down with the mouse seems to rotate the stars around the center of the screen, but I can't tell what left and right is supposed to do.

A few less stars perhaps?

What's the texture in the upper left for?

Edit
You can show images with <img src="http://url" /> tags.

Also,
threads get locked after 7 days of inactivity.

altalena

all of the calculation is done on the CPU, but allegro is also drawing tens of thousands of individual pixels with al_draw_pixel, so that may be done with the GPU, I don't know. I've got a Radeon 5450, so maybe it's GPU bound.

There's a problem with the mouse input. ev.mouse.dx and ev.mouse.dy, as you know, don't work well in full screen, but even in windowed mode, dx or dy is always -2 or 2, when the other one is zero, so I tried to fix it by subtracting the old mouse position from the current mouse position and setting my mickeys variable to zero when the mouse position along a certain axis is the same as the previous frame. This, now that I think about it, would set the mickey_x to zero if, for example, I moved the mouse the same amount twice in a row.

If I used the absolute mouse position to control the camera rotation, this would be fixed, but there would no longer be unlimited mouse movement.

I've found 4095 stars looks OK. Maybe that would work better for you. I've found the mouse works better if the frame rate is higher.

The texture on the upper left is actually perlin noise being generated in real-time for every frame drawn. It's probably slower than normal perlin noise, but I'd rather have an algorithm that I understand than one that runs faster and makes no sense to me.

Maybe if I got the mouse dx and dy some different way I could make the camera rotate more smoothly. The camera is supposed to rotate through an azimuth of 0 to 360 degrees and an elevation of -180 to 180 degrees.

Edit: I'm trying out the image embedding
{"name":"605062","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/d\/cd0a6069b7f5c22d8857bd869cf1cac5.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/d\/cd0a6069b7f5c22d8857bd869cf1cac5"}605062
http://www.allegro.cc/files/attachment/605062

Edgar Reynaldo

I took a quick look at your event loop, and you are ignoring all but the last mouse axes event. You should accumulate the dx and dy between timer events so it follows the mouse more accurately.

The manual suggests al_draw_pixel can be slow when used extensively and to consider using al_draw_prim with AL_PRIM_POINT_LIST instead.

You can also use <code>al_hold_bitmap_drawing</code> twice, once before and after your pixel drawing operations, and that may speed it up even further.</bad advice>

altalena

Thanks! I'll try to put the info to good use. I was scared of switching from devc++ to code::blocks, but the tutorials on the wiki made it quite easy.

Trent Gamblin

Just to make sure this is clear, al_hold_bitmap_drawing doesn't affect pixel drawing operations. It only works on actual ALLEGRO_BITMAPs as the function name suggests (such as al_draw_bitmap, al_draw_scaled_bitmap, etc.)

Edgar Reynaldo

I said that without thinking - all I thought of was 'hold drawing'. Would that work well with a 1x1 bitmap serving as a putpixel substitute?

altalena

I got the mouse fixed, and am using al_draw_prim, but now it crashes if I use too high a resolution or increase the size of the square full of perlin noise or the number of stars. I suspect that's a harder problem to fix.

Maybe with the al_draw_prim it will run faster. I think I'm getting 60 fps here.

I've attached updated code.

Edgar Reynaldo

Now it works like a charm for me. Much better. Smooth scrolling.

altalena

I'm wondering if I can use al_draw_prim with an array of pixels the size of the whole screen, 1024x768 for example. My program crashes when I run it if the array of noise pixels, or the number of stars adds up to too high a number.

I've attached the latest version, changed the menu a bit, changed the noise to 1 pixel square, and increased the number of stars to 20480.

Edit: Attached a new version that makes terrain - It looks a bit like Darwinia.

Edit: Now with faked terrain sort using camera azimuth

Thread #608758. Printed from Allegro.cc