Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / BlitzBasic user acclimatising to AGK, am i doing it right (sprites)?

Author
Message
Supertino
7
Years of Service
User Offline
Joined: 22nd Jun 2017
Location: Behind you!
Posted: 28th Jun 2017 00:11
For those not familiar with BlitzMax the way it handles sprites (images) is rather different, in a nutshell you have to exclusively call a DrawImage function for each image you want to render to the screen each loop. AppGameKit does this very differently drawing any sprite you've created so it's thrown me for a loop, to help I created a set of function to make me feel more at home. The code I think is self explanatory. Assuming I'll be making exclusively 2D can anyone see an issues with going forward as-is? is manipulating the depth order of sprites each loop expensive for example? How do others handle sprite rendering is there a best practice?


GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th Jun 2017 09:26 Edited at: 28th Jun 2017 09:31
You're basically duplicating the api for no reason.

I get why you're doing it. When I first started using AGK2 I was also used to working directly with images and drawing those.

Just use the sprite system in AGK. It may take you a tiny project to test it out and get used to it but it is a very logical and powerful system.

I was tempted to use the DrawSprite api method instead of using the actual sprite system but decided not to because (a) it is not as efficient and (b) I was delaying the inevitable... learning how to work with AppGameKit sprites.

It's really simple it just takes a shift in our mindset. Basically images are just that.... an image. You do all the work with a sprite.

If you ever had a C64 that you programmed for game dev you can basically see it like the hardware sprites on that.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Supertino
7
Years of Service
User Offline
Joined: 22nd Jun 2017
Location: Behind you!
Posted: 28th Jun 2017 10:07
Okay so say I have two screens\scene I want to move between, (1) Titlescreen (2) GamePlay

1. At the start of the program I load ALL the images for the entire project.
2. Just before I display the Titlescreen I create the sprites the titlescreen needs using the Images I loaded earlier.
3. Just before I display the GamePlay screen I delete the sprites I create for the Titlescreen and create a new set of sprites required for the GamePlay screen.

In all cases as I create the sprites I configure the draworder (depth).

This way I don't need to call any functions to draw the sprites as the only sprites available are ones I need and want to draw and I have already set the order in which to draw.

Okay that makes sense, is there any cost involved in creating\delete sprites on the fly?
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th Jun 2017 14:25 Edited at: 28th Jun 2017 14:40
I imagine there is some overhead. Any time we allocate/deallocate memory there is a bit of overhead involved. This is why generally you want to pool your objects.

In this case I think what you are describing is effectively pooling the sprites. Allocating all sprites at the start of the Title that are needed for the Title and then allocating all sprites needed for the Gameplay right at the start of the level.

That's basically what I do although if the amount of images and sprites (total amount for everything from title to end screens) are small I'll load all of those at the very start of the program and simply enable/disable them as needed.

I've only used AppGameKit a few times since last November but I use it the same as I would in anything else. Difference between AppGameKit and something like GLBasic, Monkey X, Blitz, etc being the sprites are managed objects here like they are in Unity. So I just track the state of everything in my own types and arrays (as always) and set the sprites visible / invisible based on their state.

I released the source for a tiny game Attack of the Crows on the forums. You might find that helpful...

https://forum.thegamecreators.com/thread/218420#msg2592697
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Supertino
7
Years of Service
User Offline
Joined: 22nd Jun 2017
Location: Behind you!
Posted: 28th Jun 2017 15:08
Thank's Ill take a look at that source when I get home tonight. I guess I could create all the sprites at program start and manage their active\visible status by group - be the same as creating\deleting on fly.

Login to post a reply

Server time is: 2024-11-22 14:45:12
Your offset time is: 2024-11-22 14:45:12