Hello
I am tring AGK for first time and I am lost... i just want to display an image
Download ok :
picture=LoadImage("landscape.png")
How to put this image on screen ??? I should create a sprite ?
there is no command like Putimage (picture,0,0) ?
thanks
That's basically it. Load the image, create a sprite from it, position and scale sprite, enter do/sync()/loop cycle.
picture=LoadImage("landscape.png")
sprite = CreateSprite(picture)
do
Sync()
loop
There is an example in the example folder images/ChooseImage shows how to load and display a background as well as choosing an image from a file requester.
Or if you want more control as to when sprites are drawn and also to be able to position sprites at screen coordinates rather than a percentage based system then ( moves a sprite across the screen ):
SetVirtualResolution( 1920, 1080 )
myImage = LoadImage( "dude.png" )
mySprite = CreateSprite( myImage )
Local x As Float
Do
SetSpritePosition( mySprite, x, 0 )
DrawSprite( mySprite )
Inc x, 1
If x > 1920 Then x = -GetSpriteWidth( mySprite )
Swap()
Loop
Of course the above doesn't take into account the different refresh rates of monitors and so the sprite will move quicker the higher the refresh rate but you get the idea of how to go about loading and moving a sprite :)
that's very strange....
images are sprites ? well... i have never seen that in a basic language :o
i do not need sprites but need to display lot of little image (about 200) on the same screen... so it seems to me very special
No, you apply an image to a Sprite, the Sprite can then be positioned, alpha values set and so on.
You can also load one image and grab sections of it to form lots of Sprites (which is much more efficient). Using a Sprite atlas.
https://www.appgamekit.com/documentation/Reference/Image/LoadSubImage.htm
Quoteimages are sprites ? well... i have never seen that in a basic language :o
AGK splits up the reference as you can do certain things with images and certain things with sprites. To keep it basic think of sprites as just the onscreen version of your image. So if you want to show 200 images onscreen you'll need to create sprites from those images first.
QuoteYou can also load one image and grab sections of it to form lots of Sprites (which is much more efficient). Using a Sprite atlas.
https://www.appgamekit.com/documentation/Reference/Image/LoadSubImage.htm
Highly recommend you learn that method as its way faster to draw loads of different sprites and also saves having to have hundreds of little files for each image.
Quote from: drfloyd on May 10, 2019, 17:51:50
that's very strange....
images are sprites ? well... i have never seen that in a basic language :o
i do not need sprites but need to display lot of little image (about 200) on the same screen... so it seems to me very special
It makes sense though, because AGK is essentially a 3D engine, even if you use it for 2D. Images are basically just containers for your texture data to keep things easily organized. Like Qube said, you can then assign them to the objects they should be displayed on.
This means you get to use the power of the GPU for your 2D games, as opposed to a more traditional 2D engine approach that just directly blits images.
You will ofcourse get less mileage out of this when just displaying static images, but for other applications it's a huge performance boost.
If you just need to load lots of images and make a big collage out of them that then doesn't change but you can't prepare the final combined image offline (because the images or their positions may change between program executions or you need to be flexible and adjust for the exact screen rez or whatever), then you could load the images in a loop and use either lots of quads or 1 quad and a custom shader to paste them together into a big rendertexture at program start and then display that final image on a single sprite or screenquad. This would lead to an extremely performant final display.
ok thanks, AGK is for 3D games (or little 2D action games)
I understand that AGK is not really cool for a RPG 2D game... I will keep BLITZ3D & BLITZ MAX for my games so... it seems that they are still the best basic languages for easy programming 2D games.
An image in BlitzMax is also something like a sprite.
These TImage things contain textures etc...which are based on TPixmap (pixel data of the loaded images).
In AGK you could surely wrap the images into something do you can simply load a PNG and draw the resulting object.
Regarding "little 2D action games"... You think Blitz3D will do better?
The 2D in 3D approach is needed for fast alpha blending and so on. Blitzmax does that too.
Bye
Ron
Quote from: drfloyd on May 11, 2019, 07:10:01
ok thanks, AGK is for 3D games (or little 2D action games)
I understand that AGK is not really cool for a RPG 2D game... I will keep BLITZ3D & BLITZ MAX for my games so... it seems that they are still the best basic languages for easy programming 2D games.
AGK is very much cool for 2D games and probably one of the best out there for it. Not sure why you think differently.
QuoteIn AGK you could surely wrap the images into something do you can simply load a PNG and draw the resulting object.
That's exactly what you can do. You can even load one png which has 100's of sprites as an atlas to reduce draw calls. So I'm not sure why drfloyd says AGK is not for 2D.
Quote from: drfloyd on May 11, 2019, 07:10:01
I understand that AGK is not really cool for a RPG 2D game...
Why do you think that? I am genuinely interested. Maybe I am overlooking something.
In my opinion AGK would be a great choice, an other similarly fitting option would be BMX + openB3D or similar addons.
They both allow for extreme flexibility, which is paramount when going for high quality and performance.
That the engine is 3D under the hood is not a negative. On the contrary, it would be silly not to use the immense power of modern GPUs for a 2D games too. (even HTML5 2D engines like Pixi or Fabric do it)
Honestly, I think you could make a 2D RPG in AGK that rivals AAA quality and still runs extremely well. (much faster than any of the big engines can achieve)
Yes, it is more effort because you have to optimize and set up a lot of rendering stuff yourself, but for that it WILL be optimized and not a bloated jack of all trades, master of none.
AGK2 is great for 2d and 3d once you get the hang of it it can be used for just about anything . I have used Blitz3D as well and going from that to AGK was a big learning curve but really worth the effort in the end . Good luck and happy programming .
Thank you,
I need to understand with an exemple
in my game, i have a grid of 1000 x 1000 cases of 16x16 pixels (16000 x 16000 pixels)... It is a RPG 8bit style map.... with about 200 differents .PNG to create the map
In BLITZ :
dim picture(200)
; load 200 pictures 16x16
for i=1 to 200
picture(i)=loadimage("case"+str$(i)+".png")
next
;and then i can combine on screen and the cases of 16x16
drawimage 0,0,picture(145)
drawimage 16,0,picture(78)
etc...
of course the screen scroll with the move of the player (as the full screen is 16000x16000 pixels)
How do the same in AGK with Sprites ?????
BLITZ
dim picture(200)
; load 200 pictures 16x16
for i=1 to 200
picture(i)=loadimage("case"+str$(i)+".png")
next
AGK
picture as integer[]
for i=1 to 200
picture.insert(CreateSprite(loadimage("case"+str$(i)+".png")) // Remember that arrays in AGK begin with index 0
next
You could then position the images like
SetSpritePosition(picture[144], 0, 0)
SetSpritePosition(picture[77], 16, 0)
Checkout SetViewOffset() (https://www.appgamekit.com/documentation/Reference/Core/SetViewOffset.htm) for scrolling the window
Also check out FixSpriteToScreen() (https://www.appgamekit.com/documentation/Reference/Sprite/FixSpriteToScreen.htm) to "fix" your HUD to the screen
You can find the "length" of an array using MyArray.length (You can also set this value). It is important to remember that although it is named "length", it is in fact
a pointer to the last entry. So an empty arrays length will return -1 and an array with one element will return 0.
There is a good guide on using arrays here (https://www.appgamekit.com/documentation/guides/12_array_changes.htm)
DrawSprite( mySprite )
The above command is used to draw the contents of a sprite to the screen. You need to position the sprite with the setspriteposition command. The agk regular sprites are like the oldskool hardware sprites and not a part of the screen. If you hide a sprite it's image dissapears from the screen. If you draw a sprite to the screen it becomes a part of the screen.
You would need to load each different tile to a different sprite.
I was writing down my own experiences(notes) with agk in this book here : https://cromdesi.home.xs4all.nl/agkmobile/appgamekitmobiletutorial.pdf
Quote from: Pakz on May 13, 2019, 09:15:04
You would need to load each different tile to a different sprite.
I don't think so.
The command you posted ("DrawSprite(spriteIndex)") states in its documentation that it _immediately_ draws the sprite at the currently defined position for this sprite.
So without any clue about AGK I would say that "Sprite" is some kind of object which has helper functions to move it around, rotate, ... and to draw the image "behind" the sprite.
So in this case you won't need 1000x1000 sprites for the whole grid/map.
You need 1000x1000 references to sprites (so eg a spriteIndex).
Then for each _visible_ grid cell you position the sprite which is referenced by the spriteIndex - and then just "DrawSprite(spriteIndex)" it.
If two neighbour grid cells use the same image this means you use the same sprite - but draw them _after_ you positioned the sprite according to these cells.
Your approach is valid IF each grid cell has individual animation positions, rotation, alpha, scale, ... but most of the time this is not true and you just need the same (mostly static) image.
As you do not want 1000x1000 sprites with all their individual settings you could cheat then: create 3-4 different sprites of a "basic image" - eg. with an offset to the animation.
Then you assign a random spriteIndex of these "3-4 different sprites" to your grid cell - leading to a map which has some randomized animation/size/color tint or whatever you've changed inbetween these sprites.
bye
Ron
I think I wrote it wrong yes. Sprites are containers :)
So 10 different tile images= 10 different sprites.
You can pack all the tiles in a tilemap (as others suggested) and then use a pretty simple shader to do the actual drawing on a screenquad, including smooth scrolling if needed. (AGK has a screenquad object that will always exactly cover the screen, this makes faked-2D very easy.)
You know the screenrez and thus how many tiles fit, so it should be relatively simple math to calculate both the tile position and the fractional scroll offset.
With so few different tiles in the tilemap you don't even need any packing for the tile-ID lookup texture, the ID fits in a single channel.
Now that I think about it, it's probably better to use two channels (it's still one lookup, no performance impact), for x and y tileset offsets respectively. Keeps the math even simpler and you are ready for much bigger tilemaps in case you want to add in more tile types later.
Just make sure mipmapping is off for the tile texture, otherwise you could get weird lines at tile edges due to the UV jumps. (because the GPU thinks "oh look, tons of texture pixels on a surface in a single screen pixel area, I can switch to the smallest mip")
This would in my opinion be the most performant way to create the ground by far.
One surface, very simple two-texture-lookups shader. Doesn't get faster than that.
Could easily reach thousands of FPS on midrange systems and the CPU side would be quick too because you are not juggling tons of objects/textures/sprites and don't need any loops going through the tiles constantly remapping them or such. Two static textures on one static object. Bam.
Any dynamic objects could then be sprites on top, as usual.
If you search on the TGC forum there is a method where you store the tiles as a font and then you just use text. Apparently it's super fast too
so each picture is a sprite objet...
on each refresh loop I should delete all the sprites on the screen ? (clearscreen do not delete images)
I cannot understand why there is not classic putimage in AGK... I hear your arguments, but cannot understand anyway ;D
Sprites are objects which you defined once. So until not hiding or moving them they seem (as said I am not an AGK user) to be rendered the same on each frame.
Means once you drew your map you hide the sprites to avoid "auto rendering" them in the next frame.
In the next frame you again move the sprites l, draw them...and after all cells you hide them again.
And yes... A simple way to draw images would help and ease the pain. Glad to not use AGK for now as this sounds like scene management in flash games of 10 yrs ago.
Bye
Ron
You could have 1 image that is used by several (totally independent) sprites, but they all share the same image ID number (which is created for you) what is so difficult about that?
Part of the code that Qube demonstrated showed this. I added another sprite with the same image (mySprite2) better to use an array of 'mySprite' rather than using another name but it shows the concept simpler.
myImage = LoadImage( "dude.png" )
mySprite = CreateSprite( myImage )
mySprite2 = CreateSprite( myImage )
The OP has an issue with:
- the requirement to create an additional (maybe even managed) object to draw an image (or part of it)
- the requirement to create an object having a load of other unneeded properties and function pointers or hower it is implemented
Our answers were also dealing with performance as he told about a 1000x1000 map - and so the best suiting solution is to find. Also he had issues with the (managed?) sprites as they are drawn there he "left" them after drawing the map. This happens with managed objects (which you add to scenes/layers/...). This is not desired here, he wants a "fire and forget" solution/command.
bye
Ron
If he has difficulty with that code I just posted then perhaps AGK is not for him, performance is irrelevant in that case.
The documentation is pretty good though, maybe some read throughs: https://www.appgamekit.com/documentation/Reference/Sprite.htm
The documentation supports my view about the unnecessarity of such a complex object for the simple task of bringing a texture to the canvas (draw image to screen).
Are you sure there is no hidden object he could use?
bye
Ron
I think there is some confusion on how AGK works with sprites.
If this is your Blitz Code :
dim picture(200)
; load 200 pictures 16x16
for i=1 to 200
picture(i)=loadimage("case"+str$(i)+".png")
next
Then your AGK code would be something like :
SetVirtualResolution( 1920, 1080 )
Dim picture[ 200 ]
For i = 1 To 200
tempImage = LoadImage( "case" + Str( i ) + ".png" )
picture[ i ] = CreateSprite( tempImage )
Next
What's complex about that?
Of course loading 200 images is not very efficient for draw calls. So in AGK you would use a texture atlas ( basically one big image with all your tiles and a text file containing all the images coordinates ) and then do something like :
SetVirtualResolution( 1920, 1080 )
atlasImage = LoadImage( "myTileSet.png" )
Dim picture[ 200 ]
For i = 1 To 200
tempImage = LoadSubImage( atlasImage, "case" + Str( i ) + ".png" )
picture[ i ] = CreateSprite( tempImage )
Next
The above method is much more efficient for drawing lots of little sprites.
Think the OP already grasped that he does not need to create a "sprite" for every grid cell of the 1000x1000 map but just for every "different" ground tile (may it be animation offset or texture/subimage wise).
But if you _did_ that way you would end up creating 1 million "complex" objects which might share texture references but hold a lot of properties which are not used for a simple "map" (physics stuff etc).
So in that case it would be "lighter" to have some light "bitmap" (or however you want to call it) object which you can explicitely draw at a position - or if you want to have it more complex a simple "TRenderable/Drawable" (position, scale, rotation, alpha, tint).
Now we all told him to not use a sprite for each grid cell but just for differen ground tiles - think we all accepted that as solution. Now the problem is that these sprites are objects on the screen which seem to be auto-rendered at the last position you set them to (as said: not a user of AGK but the OP wrote about such behaviour). This means that the sprites are auto-handled / rendered. Might make sense in some situations, but this means you would have to hide/move-to-offscreen your ground-tile-sprites after you have drawn your map with these "tile sprites".
bye
Ron
QuoteNow the problem is that these sprites are objects on the screen which seem to be auto-rendered at the last position you set them to (as said: not a user of AGK but the OP wrote about such behaviour).
AGK has two methods to draw sprites. 1) Percentage system where 0, 0 is top left and 100, 100 is bottom right. 2) Proper screen coordinates \o/
The percentage system will also just draw every sprite on screen regardless if you told it to draw a sprite or not. So if you are using this method you have to hide sprites, blah!!
The screen coordinate method ( the most sane method to use ) is enabled by calling the command, eg. SetVirutalResolution( <width>, <height> ) - Then your sprites are ONLY drawn when you use the command DrawSprite. This method also allows you to draw the same sprite multiple times on screen without having to create additional sprites of the same ID, for example :
SetVirtualResolution( 1920, 1080 )
For i = 1 To 100
SetSpritePosition( mySprite, Random( 1920 ), Random( 1080 ) )
DrawSprite( mySprite )
Next
So ( for me ) it's always easier to use SetVirutalResolution( <width>, <height> ) to allow for screen coordinates of sprites, draw sprites only when you want them to be drawn and drawing the same sprite multiple times.
thanks for all !
My final decision is that AGK is not for me :)
My RPG do not need a powerfull engine, so i prefer to continue with Blitz 3D (or something like : NAALAA, EGSL...), it's more easy with real drawing than Sprites (for my game)
Last version of my RPG :
https://www.gamopat-forum.com/t101951-cosmos-the-secret-melody-1-4-telechargement-gratuit#2922832
Thanks again for this discussion and sorry for my bad english
Hi,
Does anyone know if drawing several instance of a sprite with DrawSprite count for one draw call overall, or a draw call for each sprite ?
I would assume that sprites are optimized for reducing the number of draw call, but Draimage is not ?
So Drawimage may be very slow, especially on mobile ? It is uneasy to find some doc about how things are handled internally in AGK...
Quote from: Pingus on May 17, 2019, 01:48:27
Does anyone know if drawing several instance of a sprite with DrawSprite count for one draw call overall, or a draw call for each sprite ?
Drawing the same sprite multiple times doesn't really count as a draw call. Drawing different sprites from different textures does. This is the reason that using a sprite atlas for your sprites helps a whole heap as then you can draw hundreds of sprites from the same image rather than the GPU having to swap textures increasing draw calls. In a very basic nutshell drawing a sprite from a different texture is classed as a draw call.
I would have assumed that a draw stays to be a draw call (a polygon/quad with a texture[part] on it). Changing textures is a texture switch.
Both are "expensive" and the texture switch can get minimized by batching.
Bye
Ron
Quote
I would have assumed
You know what they say about assume, you make an ASS-out-of-U-and-ME. Well make an ass out of Pingus in this case because he's the one asking and Derron is assuming ;D
I needed to assume as I did not like to guarantee - Let's hope it is not an "End of the road" (prefer the "Gimme Gimmes" variant) ;-)
A draw call means (in my limited POV) to setup states, shaders, ... for an material thing. Dunno if AGK somehow merges together multiple images of one texture by arranging UVs on a bigger object (polygon instead of quad) or so.
I assume GaborD or other gfx gurus might be able to tell us more about it.
bye
Ron
You can check the draw calls (https://www.appgamekit.com/documentation/Reference/Benchmarking/GetManagedSpriteDrawCalls.htm)
You have it right, Derron. New texture means new batch.
AGK doesn't combine sprite textures or such as far as I know. It does try to batch sprites if they have the same texture, so that's good.
Batch counts should be fairly low unless using tons of individual textures. Even lower if (as you guys already suggested) an atlas is used.
Generally, for a sprite based 2D game I wouldn't see batch count to be an issue, would be hard to not comfortably stay under the max amount the system can handle (usually in the thousands).
In almost every case the game will be fillrate limited, as usual. The stock sprite shader is extremely simple and fast though (one tex lookup and one multiplication in the ps).
The issues start when having thousands of batches, in this case severe CPU bottlenecking can happen, especially when each batch is tiny and can be executed superfast by the GPU.
The CPU will not be able to pack and send all the tiny geometry packets quickly enough to keep the GPU happy and the GPU will start idling inbetween, waiting for data. Thus you lose performance and your app becomes CPU bound instead of using the full power of the GPU.
But this should never be the case in a simple 2D game. That said, if someone exports to a 17 year old toaster, anything can happen :)
QuoteYou have it right, Derron. New texture means new batch.
Yes a texture switch is a new draw call. At least that's the version I'm more familiar with. No doubt these days with whizzy whizzy techniques it's not as straight forward as that anymore.
QuoteAGK doesn't combine sprite textures or such as far as I know. It does try to batch sprites if they have the same texture, so that's good.
AGK does try and batch sprites and does a great job when all your game sprites are part of the same texture. It has great throughput grunt on it's 2D engine.
QuoteThe issues start when having thousands of batches, in this case severe CPU bottlenecking can happen
You are bang on with that. When dealing with 10'000's of sprites the only realistic option is for the GPU to handle that directly. Sending all that info into the GPU per frame is a real frame rate killer. From my own tests Tier 1 of AGK on a fairly decent setup can comfortably handle around 5000 sprites per frame + a good chunk of game logic.
QuoteYou know what they say about assume
To quote Under Siege 2 - "Assumption is the mother of all fuck ups" ;D
QuoteDunno if AGK somehow merges together multiple images of one texture by arranging UVs on a bigger object (polygon instead of quad) or so.
As mentioned above AGK does attempt to batch sprites together based on their texture. As AGK has atlas support built in it's a no brainier not to use it. It's much faster to use a texture atlas over individually loaded sprites.
When you assume you make an ASS out of U and ME
Quote from: Qube on May 18, 2019, 03:26:14
QuoteYou have it right, Derron. New texture means new batch.
Yes a texture switch is a new draw call. At least that's the version I'm more familiar with. No doubt these days with whizzy whizzy techniques it's not as straight forward as that anymore.
Yep, "draw call" fits too, for a discussion about drawing sprites in AGK we can indeed ignore the whizzy whizzy and just see drawcalls and batches as referring to the function call or the data being sent.
Quote from: Qube on May 18, 2019, 03:26:14From my own tests Tier 1 of AGK on a fairly decent setup can comfortably handle around 5000 sprites per frame + a good chunk of game logic.
That's the craziness of modern hardware. :)
The GPU can comfortably handle a million moving sprites/particles (well, if they are big then you'll get tons of overdraw and fillrate will kill you ofcourse), but there is no way to control them on the CPU and push all the data over. Some trickery is needed.
Quote from: Qube on May 18, 2019, 03:26:14It has great throughput grunt on it's 2D engine.
Agreed. AGK is so underrated.
People vastly underestimate how much power is available under the hood. Both in 2D and 3D. Learned that the hard way with the "fake!" complainers lol.
Agree on atlas usage for sprites. Always a good idea.
Hello
I come back...
I want to give a chance to AGK :)
If I unterstand, if i create 100 tiles, all the tiles will be on screen on the same time !!!!!
Does it mean that on each loop i should start by hide all the tiles (sprites) ?
for i=1 to 100
setspritevisible(i,0)
next
(instead of CLS or Clearscreen in other classic basic languages)
and then I decide which tiles I active + its position with :
setspritevisible(7,1)
setspriteposition(7,123,234)
sync()
is that correct ????
Qube wrote that it depends on the way you set the sprite up - relative positions or absolute positions.
Absolute positions: you need to draw them manually
Relative positions (percentage): automatic rendering except they are hidden
bye
Ron
Yes, i used Pqube method but it doesnt work. Each sprite iI load is visible
Exemple with a empty loop :
SetVirtualResolution( 320, 240 )
temp=loadimage("cache.png")
cache=createsprite(temp)
// want to draw Nothing but it draw :/
do
//setspriteposition(cache,50,50)
//drawsprite (cache)
Sync()
loop
even without drawing the sprite, it display it at 0,0... It is for that reason i ask if I should do a setspritevisible(cache,0) at each loop ?
so i try another solution :
SetVirtualResolution( 320, 240 ) // doesn't have to match the window
cache=loadimage("cache.png")
do
setspriteposition(cache,50,50)
drawsprite (cache)
Sync()
loop
the sprite does not appear, but when i activate drawsprite, it say that the sprite does not exist...
QuoteYes, i used Pqube method but it doesnt work. Each sprite iI load is visible
All you keep saying is "Doesn't work" ::) - READ THE MANUAL :P
If you read the manual you'll see that your code should be :
SetVirtualResolution( 320, 240 )
temp=loadimage("cache.png")
cache=createsprite(temp)
// want to draw Nothing but it draw :/
do
setspriteposition(cache,50,50)
drawsprite (cache)
Swap() // THIS IS WHAT YOU USE IF YOU ONLY WANT SPRITES TO SHOW WHEN DRAWN WITH THE DRAWSPRITE COMMAND
loop
Sync() will draw all sprites unless hidden.
Swap() with ONLY draw sprites that you've drawn with the DrawSprite command and does not require you to hide sprites.
@drfloyd
Keep in mind Swap() will not auto draw anything, no 3D, no sprites, no print commands (text is also in Render2DFront(), just like sprites.)
Just adding this so you don't eventually wonder why your print commands suddenly don't work. :)
Just to clarify:
Sync() is a shortcut for
Update(), Render(), Swap()
Render() is a shortcut for
Render2DBack(), ClearDepthBuffer(), Render3D(), ClearDepthBuffer(), Render2DFront()
Quote from: GaborD on May 19, 2019, 15:59:52
@drfloyd
Keep in mind Swap() will not auto draw anything, no 3D, no sprites, no print commands (text is also in Render2DFront(), just like sprites.)
Just adding this so you don't eventually wonder why your print commands suddenly don't work. :)
Just to clarify:
Sync() is a shortcut for
Update(), Render(), Swap()
Render() is a shortcut for
Render2DBack(), ClearDepthBuffer(), Render3D(), ClearDepthBuffer(), Render2DFront()
One step at a time, he's not got the hang of drawing sprites yet :P
Quote from: Qube on May 19, 2019, 16:07:39
Quote from: GaborD on May 19, 2019, 15:59:52
@drfloyd
Keep in mind Swap() will not auto draw anything, no 3D, no sprites, no print commands (text is also in Render2DFront(), just like sprites.)
Just adding this so you don't eventually wonder why your print commands suddenly don't work. :)
Just to clarify:
Sync() is a shortcut for
Update(), Render(), Swap()
Render() is a shortcut for
Render2DBack(), ClearDepthBuffer(), Render3D(), ClearDepthBuffer(), Render2DFront()
One step at a time, he's not got the hang of drawing sprites yet :P
:)
Yeah true ofcourse, but it's good to understand the basics right from the start when tinkering with the main rendering flow.
Otherwise he wouldn't know why his text is suddenly also gone.
This way it's clear that Swap() is just one standard part of Sync() and not some different magical command for sprites or such.
But I do get your point.
I progress LOL
My code is about correct ? I have created function to remember classic basics...
The problem Indeed : text has desapear ! LOL
My god why text has disapear, this is Twilight zone ?????
SetVirtualResolution( 320, 240 )
////////////////////////////// DATA //////////////////////////
dim dessinperso[2]
//////////////// charger les images ////////////////////////////
dessincache=createsprite(loadimage("cache.png"))
for i=1 to 2
dessinperso[i]=createsprite(loadimage ("perso"+str(i)+".png"))
next
//////////////////////////// GAME ////////////////////////////
do
anim=anim+1:if anim=3 then anim=1
affimage(dessincache,0,0)
affimage(dessinperso[anim],50,50)
afftexte("GROUND",11,80,180)
afftexte("DAY",10,100,0)
afftexte("HELLO WORLD ! I AM A NEWBE IN PROGRAMMATION !!!!",8,0,200)
swap()
loop
////////////////// FUNCTIONS ///////////////////////////////
function afftexte(texte$,taille,tx,ty)
texte=createtext(texte$)
settextsize (texte,taille)
SetTextPosition(texte,tx,ty)
endfunction
function affimage(image,ix,iy)
setspriteposition(image,ix,iy)
drawsprite (image)
endfunction
Quote from: drfloyd on May 19, 2019, 17:03:14
text has desapear ! LOL
My god why text has disapear, this is Twilight zone ?????
This is all explained in the manual. I highly recommend you read it ;D
To magically make your text reappear when using virtual resolutions and the swap command :
SetVirtualResolution( 320, 240 )
Local myText As Integer
myText = CreateText( "SyntaxBomb is great..." )
SetTextPosition( myText, 100, 100 )
Do
DrawText( myText ) // <--- the magic bit
Swap()
Loop
Ok, I WILL READ THE DOCUMENTATION...
Is it a real strange language, with strange features... nothing to do with Dark Basic/Blitz 3D/SDL Basic... where you can code without any help after 5 minutes.
I understand it is an advanced & powerfull language, not a classic basic, but I am surprise that TGC do not also create a real update for DARK BASIC with classic commands/functions. AGK is not the philosophy of TGC in my opinion.
Thank you anyway for all your replies. You are all very patient with newbies LOL
It 's time for me the read the doc, and if I am bored I will come back to my past languages, BLITZ or DARK BASIC
QuoteOk, I WILL READ THE DOCUMENTATION...
We have a winner \o/ ;D
QuoteIs it a real strange language, with strange features... nothing to do with Dark Basic/Blitz 3D/SDL Basic... where you can code without any help after 5 minutes.
I think it's very simple.
Just think of Sync() as doing all the draw commands for your whereas Swap() gives you more control which means you have to draw what you want on screen ( with various draw commands like DrawSprite, DrawText and sometimes use the various Render commands ).
The easiest is Sync() but you have to hide everything you don't want shown on screen. Personally I prefer the Swap() method as it gives greater control and doesn't require me to hide 100's of tiles for example.
QuoteThank you anyway for all your replies. You are all very patient with newbies LOL
We're a bunch of old grumpy coders but happy to help with a touch of sarcasm thrown in ;D
Quote
I think it's very simple.
Just think of Sync() as doing all the draw commands for your whereas Swap() gives you more control which means you have to draw what you want on screen ( with various draw commands like DrawSprite, DrawText and sometimes use the various Render commands ).
The easiest is Sync() but you have to hide everything you don't want shown on screen. Personally I prefer the Swap() method as it gives greater control and doesn't require me to hide 100's of tiles for example.
To be honest I didn't know about Swap() I've been hiding Sprites and using Sync() because that's what the example code that I've seen shows. Yes AGK is simple and very nice to use, but they do tend to add and add without a logical one way of doing things - there's always several ways to accomplish something, which is just chaos in my book.
Quotethere's always several ways to accomplish something, which is just chaos in my book.
Probably because they wanted to cater for those who want the quickest method, Sync() and those who want more control, Swap(). Swap also allows you to later up 2D on 3D or 2D under 3D. Also if you don't use SetVirtualResolution then all sprite positions are percentage based whereas if you do use that command then you can use screen positions + all the black bars are done for you in different resolutions.
Nah, sounds like a shit idea lol. I've always been of the mindset that there is always one best way to do things. C++ is terrible for that, there are soo many ways to code a solution and AGK is again muddying the waters. It seems I'm not alone in this philosophy of one best way to accomplish a task, it's Python's philosophy too so I hear. I should learn Python properly some day.
QuoteNah, sounds like a shit idea lol. I've always been of the mindset that there is always one best way to do things.
Some people love the percentage system and some love the screen coordinates system. Having both doesn't impact on the other and gives the coder the method they want to use. Had AGK forced the Sync() and percentage system on me I wouldn't be using it. I couldn't stomach having to hide every sprite not in use, let alone positioning sprites percentage based :o - Such a scenario doesn't warrant the one way only approach especially as the Swap() method allow for more draw control where needed.
QuoteIt seems I'm not alone in this philosophy of one best way to accomplish a task, it's Python's philosophy too so I hear.
What about composing music? tracker, piano roll or sheet music? :P - Options are best but I get where you are coming from in regards to coding and being able to do the exact same task in multiple ways which can be very confusing.
QuoteI should learn Python properly some day
I think you should be getting on with something else. I want to play ;D
Quote
Having both doesn't impact on the other
Yes it does because it confuses people coming to AGK. Just use one good system!
Quote
Had AGK forced the Sync() and percentage system on me I wouldn't be using it. I couldn't stomach having to hide every sprite not in use, let alone positioning sprites percentage based :o
That's just what I'm saying - it's a bad idea so why offer it too? A DrawSprite system at screen coordinates is far more intuitive than having to hide perhaps hundreds of sprites then work off a percentage system.
Quote
What about composing music?
Media is totally different to a muddled programming language structure as here.
Quote
I think you should be getting on with something else. I want to play ;D
True lol.