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.

AppGameKit Classic Chat / Tier 2 Sprite Drawing - If Sprite was created by pointers

Author
Message
XanthorXIII
AGK Gold Backer
13
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 23rd Jul 2013 21:59
Link
If a Sprite was created by Pointer, for example
unsigned int *spriteID = NULL;
*spriteID = agk::CreateSprite(Car);

Do I need to call agk:rawSprite(*spriteID) to get the Car to render to screen?
Basically what I am working on is trying to put together a SpriteManager and then make the call to draw those sprites depending on what screen I am on.
Trying to work through this logically so I can put this together that will benefit the Tier 2 group when I am done with this project I am working on.
Back to top
Profile PM
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 23rd Jul 2013 23:31
Link
I don't think you do because when you use the createSprite function, the sprite is created in AGK's internal sprite manager which draws it for you.

I no longer use integers to handle sprites but instead I use AGK's cSprite and cImage classes. Sprite creation for me often looks like this:
cImage* img = agk::GetImagePtr(agk::LoadImage("image.png"));
cSprite* spr = agk::GetSpritePtr(agk::CreateSprite(img->GetID()));

And then you can simply do things like:
spr->SetPosition(10,10);

Using this method, the sprite is still rendered automatically since it's in AGK's sprite manager.

Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 23rd Jul 2013 23:33 Edited at: 23rd Jul 2013 23:34
Link
XanthorIII, the code you show probably won't work.

The CreateSprite command takes one or two calling parameters. If you use only one, it is expecting an ID for an image (or zero, and then it creates a blank sprite) and returns an ID for the sprite created. In Tier 2, both of those are unsigned ints. If you pass two parameters (both of them UINTs), then it creates the sprite with the ID that you pass using the image ID (the second parameter).

The code you show has a variable that is a pointer to an unsigned int and it has a null value. That means it is not pointing at anything.

If you then executed the CreateSprite command as you show it, your app will crash because you are trying to de-reference a pointer that has not been assigned.

If we assume that the code you show is all of it, it definitely fails. If you had somewhere assigned a value to your spriteID variable, you might then get a sprite that is blank (unless Car is another variable containing a valid image id from an LoadImage command).

But, assuming you are using the standard CreateSprite command and store the return value in a plain old unsigned int variable (and Car is an unsigned int with either zero or a valid image ID), then you would get a sprite. And you would not have to manage drawing it.

Using the vanilla CreateSprite command adds that sprite to the set that is somewhat automatically handled (at least for drawing and physics and such).

What are your trying to do?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 23rd Jul 2013 23:35
Link
Hodgey, do things get done faster if you use the cSprite class (with pointer created as you show) than if you use the standard sprite commands?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
unlikely
12
Years of Service
User Offline
Joined: 5th Mar 2012
Location: Ohio, USA
Posted: 24th Jul 2013 00:12 Edited at: 24th Jul 2013 00:26
Link
Theoretically:

would work.

But why?


For the 48 hour jam, I started a little entity framework that uses agk:: functions behind the scenes. Essentially, my class instances keep track of their own spriteIDs and perform their tasks using the agk engine. I then have an entity manager class that is in charge of creating entities and calling their custom update.

Additionally, the manager is in charge of collision management and creating new entities, since it keeps a list of available and used spriteIDs in its assigned range. This is needed because of the way physics collisions are implemented in AGK. If I want to check for bullet collisions with enemies, I can go through my bullet entity manager and check the collision points for each bullet. I have a list of the created bullet spriteIDs, so I don't have to query each bullet entity object for it's spriteID and then query my enemy entities for theirs. I can also have the manager simply reuse sprites from an already allocated sprite pool for something like bullets that are created and destroyed extremely often. It helps efficiency quite a bit.

I'm starting to think building my framework on the AppGameKit classes (cSprite, cImage, etc.) would have been a better option organizationally.


EDIT: For misread OP...
Back to top
Profile PM
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 24th Jul 2013 00:19 Edited at: 24th Jul 2013 01:30
Link
Quote: "XanthorIII, the code you show probably won't work."

I missed that - nicely spotted. I was just reading intention.

Quote: "Hodgey, do things get done faster if you use the cSprite class (with pointer created as you show) than if you use the standard sprite commands?"

I personally haven't noticed any speed ups (but I've only tested my app on a PC and Mac so it runs quickly anyway) but I imagine (need Paul to confirm) that it would save a function call or two.

My educated guess is that SetSpritePosition(spr, x, y) would call the sprite located at spr (possibly hashed) and then will call spr->SetPosition(x,y). So in psuedocode:
void SetSpritePosition(spr, x, y) {
cSprite* s = getSpriteFromHashList(spr);
s->SetPositino(x,y);
}

The other benefit is that it saves typing in the long run - you don't need to type 'agk::' and the sprite commands are shorter.

Back to top
Profile PM Email
XanthorXIII
AGK Gold Backer
13
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 24th Jul 2013 01:06
Link
Don't take the example Literally. I was typing quickly. I also should have thought my example through a bit better.

The end goal is to build Scenes that will only display the Sprites that are assigned to them.
So I have a Splash Scene, a Menu Scene, a Game Scene etc...
Splash Scene has all the objects that make it up, same for Menu etc...
When I switch between scenes, I only want to draw the objects associated with that Scene. Now I don't want to call a bunch of SetSpriteVisable functions just to hide/unhide Sprites between Scene Transitions.
Back to top
Profile PM
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 24th Jul 2013 01:34
Link
Quote: "Now I don't want to call a bunch of SetSpriteVisable functions just to hide/unhide Sprites between Scene Transitions."

I imagine that you have a Scene class? What you could do is create all of the sprites in the constructor and delete them all in the destructor (probably what you're doing). So then, all you need is only one scene at a time and as you move from scene to scene, you delete the old one and create the new one. Moving back an forth between scenes will result in repeatedly creating and deleting the same sprites but that way you will reduce your memory footprint and don't have to call SetSpriteVisible().

Back to top
Profile PM Email
george++
AGK Tool Maker
17
Years of Service
User Offline
Joined: 13th May 2007
Location: Thessaloniki, Hellas
Posted: 24th Jul 2013 19:41 Edited at: 24th Jul 2013 19:43
Link
I think, the SetSpriteVisible is your way.
Here is a very basic example

Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 24th Jul 2013 20:13
Link
As long as your build defaults to zero and one for false and true, this might work.

But the agk::SetSpriteVisible command takes an integer value for the visibility flag.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
The Daddy
15
Years of Service
User Offline
Joined: 13th Jan 2009
Location: Essex
Posted: 27th Jul 2013 21:17
Link
Whichever way you do it you will have to loop through either setting the positions or making the sprites visible each change of scene.

There is another very speedy, but not memory efficient way of doing this. Lets assume a scene is one screen in size (no scrolling - this can be done but is more complicated!). Each scene will have a virtual x and y position. Whereas the real pixel screen starts top left at 0,0... The first scene could have virtual 0,0 the second scene 640,480 (whatever your display size) but they must not overlap.

So your sprites for scene zero (virtual x,y = 0,0) are positoned as normal. For scene two with a virtual x,y of (640,0) your sprites will be position with an offset of 640 on the x! And so on and so on...you create all your scenes and set visible all of your sprites!

Al the sprites will be drawn but only those on the current scene will be seen by the user!

Simples! Super fast switching between scenes! May have a memory issue with hu dreds of scenes.

www.bitmanip.com
All the juicy you could ever dream of!
Back to top
Profile PM Email Website
XanthorXIII
AGK Gold Backer
13
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 29th Jul 2013 17:34
Link
@The Daddy
I just thought there was a simple way of drawing the sprites myself using the draw command. Resorting to what you suggest would probably not be a good practice nor practical. While it may work and I appreciate the idea, I want a good solid solution to this.
That means being able to display a scene at any given time and the objects associated with that scene using a method on the scene object.
George++ gets a little closer to what I want.
I guess in the end how taxing is the SetVisible function and what will that do to the run time.
That was my big concern.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-24 18:28:22
Your offset time is: 2024-11-24 18:28:22