Messages

Could be memory related, its using 47mb worth of images for the level alone, which somehow boost the total system ram to almost 200 on one computer I was testing on.  I could split the maps up more and only load several at a time instead of all 9 sets of 3.

Also there's some jerkiness as new level images get swapped in.  I may have somewhat fixed that, but like I mentioned I may need to break the images up, probably 18 sets of 512x576 images.  I also found I had gaps between the level parts from overlapping and made images clip to the view screen.  Still a few more things to do, and possibly a new version of the level, some thought the navigation was too narrow.

I didn't take into consideration the palette part, but that does make sense.

Also an 8bit PNG can be larger than 24bit PNG, most likely due to the palette data.

Previously when working with 8bit graphics I was using GIF files, since they are pretty nice for limited colors and produce smaller files in that regard compared to PNGs.  That and animation capabilities.  Both can have transparent backgrounds.  However it seems that GIF support is dying out.

I recall in the past GIF was kind of a dead fish due to some very strict and stupid license it, preventing it from really moving beyond a simple web graphic.  That expired many years ago, but too late really.

I've replaced the use of drawsprite with a simple command that creates a polyvector instead, due to improved performance and greater flexibility that polyvector provides.  Also since I'm using large graphics and there is clipping, I updated the command to be a little smarter, only drawing in the screen and what is visible.

screen_width and screen_height need to be defined by you though.  Doesn't have scaling or rotation features yet, but I need to do them soon for my project.

Code (glbasic) Select Expand


  FUNCTION DrawPolySprite: image, x, y, w, h, color
    LOCAL adjx = x, adjy = y, adjw = w, adjh = h, adjsw = 0, adjsh = 0, adjpw = w, adjph = h
    //Optimize
    IF x < 0
      adjx = 0
      adjsw = -x
      adjpw = w+x
    ELSEIF x+w > screen_width
      adjw = w+screen_width-x
      adjpw = adjw
    ENDIF
    IF y < 0
      adjy = 0
      adjsh = -y
      adjph = h+y
    ELSEIF y+h > screen_height
      adjh = h+screen_width-y
      adjph = adjh
    ENDIF
    //Create
    STARTPOLY image, 0
      POLYVECTOR adjx, adjy, adjsw, adjsh, color
      POLYVECTOR adjx, adjy+adjph, adjsw, adjh, color
      POLYVECTOR adjx+adjpw, adjy+adjph, adjw, adjh, color
      POLYVECTOR adjx+adjpw, adjy, adjw, adjsh, color
    ENDPOLY
  ENDFUNCTION


I noticed using only colors instead of a texture in 3d and 2d polygons can slow things down on certain systems, which is wierd in a way.  Think it would be possible to have an alternate polyvector and x_objaddvertex with an alpha flag?  I know from working with Direct X in Game Maker I was able to setup polygons with alpha values to create some nice effects like gradual opacity from transparent.

When playing around loading graphics, I noticed that I had problems using images that greatly exceeded the height of the screen but not the width.  I was able to use a 1760x608 wide image, but not a 1024x800(image got squished), although I believe I also had squishing issues when using a 1024x600 vs a 1024x576(which I'm using now)

This probably just confusing things, but  the working images were divisable by 16 (600 vs 576), but both are powers of 8.  In relation, if I used a texture smaller than 16x16 in a 3d model the texture would not correctly fill the model face.

Got a chance to check it out...

So with my demo using 37 1024x600 images:


BMP(24bit)
   Total Size = 46mb
   Zipped Size = 3.6mb
   Game Loadtime = 4 seconds
PNG(24bit)
  Total Size = 5mb
  Zipped Size = about the same
  Game Loadtime = 4 seconds

I guess the next thing to check would it be beneficial to degrade the color capacity to 8bit colors for further performance.  At least done to the tile layers but not the glow layer(would kill the gradients).  Anyone know if using 8bit images has any effect when loaded into the game than higher bit rates?

I know I could do without, but I really like dimpush.  I don't have to deal with setting ranges for loops, just use foreach statements.  Then I also don't have to worry about a status variable.

Whats the specs on your laptop?  I run this fine on a Netbook w/ atom and on a G5(old)

I do all my own graphics, thanks.

You can have a sprcoll check using a simple sprite with the mouse's x & y coordinates.  You don't have to draw any sprites to do a sprite collision.

Well I can check it out later tonight and see.

The tech demo I have below(PC & OSX) uses 27 1024x600 24bit png images, it eats a bunch of loading time.  So I can try converting them to BMPs and see if there is any improvement from it.

http://www.glbasic.com/forum/index.php?topic=4413.0

http://host-a.net/scott_aw/RickJason_OSX.app.sit
OSX version

should be the same as

http://host-a.net/scott_aw/rj_tech3.zip
WIN3d version.

Hopefully I'll get an linux OS to test with soon, any suggestions?

I like PNGs because of their loss-less compression, and they help in reducing overall program size on disk, but is there an improvement in the time it takes for loading graphics if you use uncompressed BMP files?

You could combine some textures into a 'tilemap' and manipulate the texture x,y accordingly.

That would be useful to be able to batch like textured objects.

Netbook's may not be powerhouses, but they handle pretty well.  Their low-cost, which is decreasing as models are ranging from $200-260 at the lowest for new units.  With the low price it can grab a larger audience and open doors for less developed nations. 

I see a lot of benefit with netbooks and tablets being made with the Atom since it will provide a pretty good standard.  Although personally I would like to see AMD come out with Netbook worthy CPUs soon if they haven't started already.  I've always preferred AMD over Intel since they have less shady practices in their history with chips.

Kind of interested in ARM still, I would like to play around with Android and CE based OS systems.  ARM units I believe are cheaper than the ATOM, but with several drawbacks.

I could try that for categorizing up my functions and subs. 

You know what would be nice?  Comment goto's that only effect the jump list.  I put little goto like "topcode:" and "midcode:" and so on to make navigation through code easier.  Can we have a commented out version that is just for navigation and not used in-code?

Hope I explained this right.