Image System
Blitz3D Forums/Blitz3D Programming/Image System
| ||
| I'm going to have a heads-up display for my game that shows things like health, ammo and everything. However I'm still trying to decide what is the best method to go about doing this and other 2D graphics. I am still pretty new with Blitz so I need some advice about what method I should use as my knowledge of image commands is still pretty sketchy. The easiest method would obviously be to just load the images and apply them to the screen after a call the RenderWorld(). However because I will be running the game with a setup method that allows for multiple screen resolutions (I cannot assume everyone can use just one), am I correct in my assumption that all these images will need to be scaled? Or does Blitz do this manually whenever you load into a different resolution? Because if I have to scale them this could lead to all sorts of math related problems as the images should maintain a constant size despite the screen size... Any ideas or possible methods of implementing this? |
| ||
| It would be much better to use sprite entities or quads to display these as on some cards performing 2d operations like "drawimage" while in 3d mode will degrade performance significantly. |
| ||
| Sprites will be effectively scaled because the camera view would always appear the same. If you are using 2D images, I would utilise ScaleImage and GraphicsWidth()/GraphicsHeight() to calculate and maintain the ratio. Somkething like: Note: it's earl;y - Im tired I have no access to blitz so dont necessarily trust this code (I dont!) it's just the principle I'm trying to get across! |
| ||
| I'd say use Quads too. If they are once positioned right, you can simply hide and show them, and they allow to use alpha transparency, even each pixel with its own transparency using the alpha channel of eg. a 32 Bit Tga Texture. there are lots of benefits with quads, eg. you can use diffrent blending modes, like multiply, that looks very shiny. The only problem is, since you are using multiple screen resolution, the textures won't be pixelperfect. You can do pixelperfect quads, but if you want to make it work in multiple resolution, you may need to load the textures screen-resolution dependant. Anyway, it isn't so bad when the textures are not pixelperfect. Pixelperfect mean, each texel will use exactly one pixel on the screen. The object must be positioned in a way that it fits exactly on the screen. Example: Let us assume our current screenresolution is 1024*768 and we have an Image here of 1024*768 Pixels size.
graphics3d 1024,768,32,1
setbuffer backbuffer()
testbmp=loadimage("mybmp.bmp")
cleartexturefilters
tex=createtexture(1024,1024,256 or 16 or 32)
texturefilter "",9
copyrect 0,0,1024,768,0,128, imagebuffer(testbmp),texturebuffer(tex)
quad=createQuad()
entitytexture quad,tex
entityfx quad,1
camera=createcamera()
camerarange camera,0.01,100
translateentity camera,(1.0/1024.0),-(1.0/1024.0),-1.0
parententity quad, camera
setbuffer backbuffer()
while keydown(1)=0
renderword()
text 0,0,"Texture Version"
if(millisecs() and $1000)=$1000 then
drawblock testbmp,0,0
text 0,0,"Image Version"
endif
flip
wend
end
function CreateQuad()
mesh=createmesh()
surf=createsurface(mesh)
v0=addvertex(surf,-1.0, 1.0,0 ,0,0)
v1=addvertex(surf, 1.0, 1.0,0 ,1,0)
v2=addvertex(surf, 1.0,-1.0,0 ,1,1)
v3=addvertex(surf,-1.0,-1.0,0 ,0,1)
addtriangle(surf,v0,v1,v2)
addtriangle(surf,v0,v2,v3)
updatenormals mesh
return mesh
end function
It will now switch frequently from image to texture mode. You shouldn't see any diffrence. This is pixelperfect. |
| ||
| Nsprite www.nuloen.com costs about ten bucks but its worth it |
| ||
| Black Hydra Performance I agree with the others in using 3D sprites/meshes. In Fact, You can achieve 'pixel perfect' textured sprites identical to a 2D image. Hispeed transformations and alpha blending are easily accomplished 3D. Complexity Another consideration is complexity. Some games do not require complex GUI Controls like comboboxes, listboxes, and Treeviews. Somes games do. If your game requires some of these complex controls then you might be interested in 3rd Party GUI Library. Writing such a GUI system is very time consuming. Editing Creating the GUIs should be considered as well. You'll probably design and redesign your gui several times before it goes in game. Easy to use Editing Tools sure beat coding orientation of the controls by hand. Take this in to consideration if you want to avoid frustration. There are several FREE 2D GUIs available that are designed for handling complex controls. Some come with an Editor! These Libraries provide a good starting code base if you want extend them for 3D. |
| ||
| Well currently I don't need any complex GUI stuff for my game as it just has the pretty standard HUD and main menu. So no tree menus or anything like that. Use 3D? Hmmm... never thought about that, but it makes sense. I suppose I could just make a sprite, lock it to the camera and then use the standard entity operations to affect the visuals. Anyone know what scales I would need to scale the sprite in order to have it fill the entire screen, then I could just use percentages of this in order to position it on the 'screen'. I suppose I could just experiment, but that isn't very precise. As for GUI's I may buy one later as I am going to need a menu for my game, and I'd rather not have the hassle of making one myself. Thanks for the help you guys! |
| ||
| Has anyone tried to use Cameraveiwport for something like this? Would there still be a speed problem if you section off part of the screen for 2d drawing? |
| ||
| Anyone know what scales I would need to scale the sprite in order to have it fill the entire screen This would depend on the size of your sprite texture, and the CameraRange minimum range, the distance between the sprite and camera and a fair bit of trial and error. |
| ||
| Here is a piece of code based on a few peoples' work, but most thanks to Rob (Redflame). It's pretty accurate in placing (x,y) and width/height(w/h) in screen coordinates, so it can be placed like a 2D box, but of course has all the attributes of being able to alpha,texture etc.. It also remains pretty accurate even with different CameraZoom values. I only cracked it today, so there's a long way to go. The only downside seems to be that you need a long CameraRange far value. Global nWinWid=800,nWinHit=600 Global camera,light,cube,hud Global nCameraZoom# = 1 example() ;------------------------------------------ Function example() ;------------------------------------------ Graphics3D(nWinWid,nWinHit,0,2) SetBuffer BackBuffer() camera=CreateCamera() : CameraZoom camera,nCameraZoom# : CameraClsColor(camera,34,85,136) : CameraRange camera,1,10000 cube=CreateCube() : EntityColor(cube,64,64,64) : MoveEntity(cube,0,0,4) : EntityAlpha(cube,0.75) light=CreateLight() : MoveEntity(light,10,3,1) hud = HudCreate() : HudParent(hud,camera) While(Not KeyHit(1)) TurnEntity(cube,1,1,1) UpdateWorld() RenderWorld() Text nWinWid/2,20,"HUD-mesh parented to camera test",True,True ; HUD HudMove(hud,200,150,400,300) ; x,y,w,h ; Camera-Zoom If KeyDown(200) Then nCameraZoom#=nCameraZoom#+0.01 : Delay 100 If KeyDown(208) Then nCameraZoom#=nCameraZoom#-0.01 : Delay 100 If nCameraZoom#<1 Then nCameraZoom#=1 CameraZoom camera,nCameraZoom# Text nWinWid/2,nWinHit-20,"^/v CameraZoom "+nCameraZoom#,True,True Flip Wend End End Function ;------------------------------------------ Function HudCreate() ;------------------------------------------ Local m,s m=CreateMesh() s=CreateSurface(m) AddVertex s,-1,+1,-1,0,0 : AddVertex s,+1,+1,-1,1,0 AddVertex s,+1,-1,-1,1,1 : AddVertex s,-1,-1,-1,0,1 AddTriangle s,0,1,2 : AddTriangle s,0,2,3 EntityBlend(m, 1) ; alphamode, use 1 or 3 EntityAlpha(m, 0.5) EntityOrder(m, -1000) EntityColor(m, 255,255,255) Return m End Function ;----------------------------- Function HudParent(hud,camera) ;----------------------------- EntityParent(hud,camera) End Function ;------------------------------------------ Function HudMove(hud,x#,y#,w#,h#) ;------------------------------------------ Local cx#,cy#,px#,py# cx# = x#+(w#/2) cy# = y#+(h#/2) px# = 2*(cx#-(Float(nWinWid)/Float(2))) py# = -2*(cy#-(Float(nWinHit)/Float(2))) ScaleEntity(hud,w#,h#,1) PositionEntity(hud,px#,py#,nCameraZoom# * nWinWid) Text x#+10,y#+10,"HUD-test" End Function |
| ||
| Wow, that looks pretty cool. I'll have a better look through it when I get some time, but it looks like it should work. I won't be changing the camera zoom in my game (at least to my knowledge) so that is sort of an unused goodie. Even so, it saves me the time of building functions for these things. |
| ||
| It's not that I change CameraZoom necessarily, but mine is permanently set to 1.3 (because I think it looks more natural) so the code had to cope with that. As far as trying, just copy and paste my code into a blank Bltz page, and run it. The fun starts when you realise that you can use EntityTexture to add a texture to the HUD, or start playing with EntityColor and EntityAlpha. |
   |