Main Menu

what happens when i run a game?

Started by stevmjon, January 24, 2006, 07:28:48 AM

Previous topic - Next topic

stevmjon

to kev

 out of interest, i would like a basic knowhow of what the computer handles when a game is run.  since a game is mainly images, used for sprites, scenery, backgrounds, fx etc, what does the cpu handle and what does the videocard handle. this was briefly explained in the maintenance section under bugs in mirror image problem, but i would also like to know which memory is used. is system memory used and video memory used, depending on what mode the image actually is, or is everything system ram.
how much memory do arrays() and variables use, because i have an awful lot of them.
if i have a lot of images in the game, is this all stored in system ram or video ram, until its displayed.
are sounds stored in system ram, or on a sound card.

i would love to improve my knowledge in this area. not too complicated though.

the reason i ask, is because i ran my game on my newish computer and it runs fine, and if i disable setfps, it runs at 250 fps with a full screen of active sprites. i then tried it on an old computer,set to 50 fps, with a very basic graphics card and it ran so slow the game was unplayable. it also wouldn't play in full screen mode at all. this old computer is a celeron 800mhz processor,128 meg ram, with an ati rave IIc graphics card.
out of interest, i put a much better graphics card in it, left all other hardware the same, and then it ran fine with no problems, in full screen mode or windowed mode.

i have spent 11 months making my game engine so far, at over 4000 lines of code, but i would like it to play on older machines as well as new ones. a little more insight will allow me to make necessary changes, or set minimum requirements. my game is a platformer, with a large amount of weapons and items. i want to make it as enjoyable to play as i can. i am also making an editor to allow easy level making. hope to have the game engine finished by easter, so i can post a demo level and get some input. looking forward to it. :lol:

 thanks stevmjon
It's easy to start a program, but harder to finish it...

I think that means i am getting old and get side tracked too easy.

kevin

#1
Quoteout of interest, i would like a basic knowhow of what the computer handles when a game is run. since a game is mainly images, used for sprites, scenery, backgrounds, fx etc, what does the cpu handle and what does the videocard handle. this was briefly explained in the maintenance section under bugs in mirror image problem, but i would also like to know which memory is used. is system memory used and video memory used, depending on what mode the image actually is, or is everything system ram.


 Video images are stored in Video Memory.   Which is the default mode.  Any image stored in Video Memory is rendered using the Video cards GPU  (it's blitter in fact)  

 FX images are in system memory.  


Quotehow much memory do arrays() and variables use, because i have an awful lot of them.


  Integer Variables  = 4 bytes per variable
  Float Variables  = 4 bytes per variable
  String Variables =  4 byte pointer + length of the string in bytes


Arrays

    For integer +float array you mult the dimensions out, which give the cell number,  then mult that by the data width and add on the header size of about  128 byte of memory.  

  Ie.

   Dim Table(100,100)   =  128+((101*101)*4) bytes

   Dim FloatTable#(100,100,50)   =  128+((101*101*51)*4) bytes

   Strings arrays are really are look up table to each individual string.  So it depends on whats stored in each cell..  But lets say the you store the 256 byte string in each cell.   You calc it's size a bit like.

 Dim StringTable$(100) =  128 +(101*4) +(101*256) bytes.
 


   NOTE: - In modern versions of PlayBASIC, you can see exactly how much memory your program uses from the PlayBASIC Debugger.  (F7 to run in light debug mode)



Quoteif i have a lot of images in the game, is this all stored in system ram or video ram, until its displayed.

  Depends upon type.  If these are Video images, the live in video memory always.  FX images live in system memory.



Quoteare sounds stored in system ram, or on a sound card.

  Sounds sit in sound card memory.  The only exception is when playing 'music' as the data can be spooled off the disc, rather than cached in memory.



Quotethe reason i ask, is because i ran my game on my newish computer and it runs fine, and if i disable setfps, it runs at 250 fps with a full screen of active sprites. i then tried it on an old computer,set to 50 fps, with a very basic graphics card and it ran so slow the game was unplayable. it also wouldn't play in full screen mode at all. this old computer is a celeron 800mhz processor,128 meg ram, with an ati rave IIc graphics card.
out of interest, i put a much better graphics card in it, left all other hardware the same, and then it ran fine with no problems, in full screen mode or windowed mode.

    I can't say I'm surprised.  Performance will vary system to system   The general rule is the higher the pixel count, display resolution  and display depth !,  the more absolute brute force is required to shift it at reasonable rate.

 For example

  If you use a   1048x * 768y  32bit display mode .  That's  (1024*768*4)=3,145,728 bytes for the screen.  Yes 3 meg !

  Now lets say you CLs the screen and draw one layer of  map to it.   That means your GPU is  roughly shifting  3 meg for the clear, and another 3 meg for the tile layer render.   So to draw the image costs 6 meg of bandwidth per frame.

  Every single pixel that is rendered (solid or transparent - the later is slower)  costs you performance! While Modern GPU's have a much higher fill rate (the cost per pixel), older ones simply won't cope when presented with such a mountain of data.

 You can reduce the work load by lowering the display depth (from 24 or 32bit to 16bit)  This halves the amount of data that has to be shifted.  It's also worth noting the many older GPU's were optimized for 16bit displays over 24bit or 32bit modes.  

 Moreover, Don't assume older machines even have a 32bit mode,  many don't ..
 

 Another tip is optimizing your image sizes.   Since transparent rendering is slower than solid,  use solid where ever possible.   If you have to use transparent images (i.e sprites or in mapping)  try and make sure the size of the image is no larger than the image content. As rendering blank (clear/transparent) pixels is a huge waste of processing time.  

 See bellow



Quotei have spent 11 months making my game engine so far, at over 4000 lines of code, but i would like it to play on older machines as well as new ones. a little more insight will allow me to make necessary changes, or set minimum requirements. my game is a platformer, with a large amount of weapons and items. i want to make it as enjoyable to play as i can. i am also making an editor to allow easy level making. hope to have the game engine finished by easter, so i can post a demo level and get some input. looking forward to it.  

 Cool, I know i'm looking forward to it !


kevin

#2
Rendering transparent pixels costs.


PlayBASIC Code: [Select]
Dim Results#(2,2)

TestTime=10000

;TEst #1 -

Size=32

; create a 128 *128 image with circle on it for something to look at
Image1=Newimage(128,128)
Rendertoimage Image1
circlec 64,64,size,1,$00ff00


; create a 64*64 image with circle on it for something to look at
Image2=Newimage(64,64)
Rendertoimage Image2
circlec 32,32,size,1,$ffff00


rendertoscreen


test=1
TestLength=timer()+TestTime
repeat
Cls 255
print "test #"+str$(test)
print "seconds left"+str$((TestLength-timer())/1000)
t=fps()
print t
Results#(Test,1)=Results#(test,1)+t
Results#(test,2)=Results#(test,2)+1


iw=getimagewidth(image1)
ih=getimageHeight(image1)
For lp=0 to 100
drawimage image1,(lp*5)-(iw/2),100+(lp*3.5)-(ih/2),1
next

Sync
until Timer()>TestLength



inc test

TestLength=timer()+TestTime
repeat
Cls rgb(255,0,255)
print "test #"+str$(test)
print "seconds left"+str$((TestLength-timer())/1000)


t=fps()
print t
Results#(Test,1)=Results#(test,1)+t
Results#(test,2)=Results#(test,2)+1

iw=getimagewidth(image2)
ih=getimageHeight(image2)
For lp=0 to 100
drawimage image2,(lp*5)-(iw/2),100+(lp*3.5)-(ih/2),1
next






Sync
until Timer()>TestLength




cls rgb(30,40,80)


For test=1 to 2
print "Test "+str$(test)
totalfps#=Results#(Test,1)
frames=Results#(test,2)
AverageFps#=TotalFps#/Frames
print "frames drawn:"+str$(frames)
print "Average Fps:"+str$(averageFps#)
print ""
next

drawimage image1,100,100,0
drawimage image2,400,100,0



sync
waitkey










stevmjon

to kev

thanks for your info. it has helped me understand the processes that goes on. i now know the adjustments i need to make. you have a good knowledge on computers and programming.

the above demo for drawing pics showed a difference. the pic with a lot of transparency averaged 512 fps, and the pic with little transparency averaged 589 fps, on my system. i did not realise transparency cost extra time.

     thanks stevmjon
It's easy to start a program, but harder to finish it...

I think that means i am getting old and get side tracked too easy.

kevin

Well, i've been doing this type of coding for a little over 20 years now.    While the toys get better in some ways, many things have got worse. but on the whole nothing much has really changed.


While a simple demo,

    Test 1 is rendering 101 * (128*128)  pixels (1,654,784)
    Test 2 is rendering 101 * (64*64)  pixels (413,696)


 Anyway, on my Duron 800 mhz  / geforce 2 mx system


800*600*32bit (window)

 test 1 = 35 fps
test 2 = 76 fps



800*600*32bit (Full screen)

 test 1 = 49 fps
test 2 = 137 fps



800*600*16bit (Full screen)

test 1 = 99 fps
test 2 = 251 fps


You get the idea.  Less ='s more.  Often getting the best results is more about design, then brute force.

 It's also worth noting that full screen exclusive  is generally going to outperform windowed mode on old clunkers.    Again since the fill rate of the GPU is slower.