Sorry your browser is not supported!

Nothing crucial here but I wanted to comment on something that became apparent while I was working on a game or, more specifically, the level creation portion of the game. Someone may be able to give me some advice, however, on a better approach to take.

My game is structured on a set of classes I've created that wrap the Dark GDK 2D functions, sprites and images. I've done bitmap too but have managed for the most part to transfer the bitmap capabilities to my Image class. AAR....

My level creation has a panel on the right side over which I display 60 sprites that I can drag and drop into a grid on the left side. Although I'd drawn the grid I hadn't really developed the map for the grid. A couple of days ago I designed and declared the grid map, which is composed of Capsules, a child of my Sprite class. The grid is 11 by 20, or 220 Capsules. What a revelation. My program, which had been running at 60 FPS slowed down to 40 FPS.

This is with little in the way of computation taking place during idle times. The only thing I had going on was a moving ball and a paddle that cruises the bottom of the screen. None of the Sprites/Capsules had a valid image applied to them although a number for the sprite itself was assigned and a dbSprite () was issued. This morning I added a function to my Sprite class that allows me to Invalidate() it by making sure that the DGDK system doesn't track a number for it. With this in place for all empty grid positions my FPS jumped back up to 60.

What I've come to realize is that DGDK needing to track 280+ sprites, even though they're not even visible, seems to consume a considerable amount of CPU power. Most importantly to me is that the interactivity between images and sprites creates considerable confusion with my class now.

My feeling now is that I need to create a Sprite object under an invalid flag, without trying to assign an image to it on creation (or at least as a polymorphic option) and assign an image as a separate function then validating the two.

Note: While checking my facts and trying some new approaches I think I'm closing in on making this work. What I'd like would be some opinions as to what makes a sprite valid and how to create one in the GDK without having to set a position while hiding it at the same time.

If I understand you correctly, you're asking how to create a sprite without actually giving it a number or (x, y) position, correct?

If that's the case, then I'm not sure it's entirely possible in the GDK. I think you would have to move to DX. But, I don't know as much about it as others. It's this very reason I want to learn DX.

It's more or less the x/y position I'm concerned about. From a procedural point of view you basically call the dbSprite() function with a sprite number and an image number. You can test for the existence of the image first and if it's okay then call dbSprite() and test for the existence of the sprite. Of course, if the image doesn't exist, the sprite won't exist either.

The problem is that I'm doing this with OOP and what I want to do is pair up the sprite and image numbers without necessarily activating the sprite in GDK space initially. I also want to be able to preset things like diffusion, offset, etc. I keep local variables in the class that I'd like to set before activating the sprite. In essence I'm finding that I need to set up a lot of things that are otherwise default and sync from the local variables to the GDK sprite data just to keep the two aligned. When I'm ready to activate the sprite, then I want to tell GDK to set it up in GDK space. I'm making progress but I'm finding I'm having to get some convoluted coding going.

I also want to deactivate the GDK copy when the sprite isn't in use so as to hold down on what GDK needs to handle but be able to call it back into service when necessary.

I was pretty certain I wasn't really finished with my Sprite class. Looks like I've got more work to go. When I'm a little bit along I'll post a version of my level editor. I might even ask the forum to contribute levels to the game when things are far enough along.

I would keep track of your numbers internally (possibly even generate them from the object name). When created, simply load the image into the chosen number. When you use your command for drawing, call dbSprite. When you use your command for hiding/clearing, call dbDeleteSprite. You may have been asking something much more complex than that, though.

That's roughly what I'm doing. I'm keeping a static counter called nextSpriteNumber that is used to assign a number to the Sprite object on construction and gets incremented for the next object to use. The one concern is that I'm attempting to keep that counter under control and if a Sprite goes out of scope it should, hopefully, decrement the nextSpriteNumber counter if the sprite number that's disappearing is 1 less than the counter. I'm sure I can think of a better way but I'm also considering the CPU time necessary to keep decrementing until the numbers line up with what GDK thinks are active.

Hmmm... I'm not sure exactly how efficient you could make the system to keep track of the sprite number. Give me a bit and I might be able to think of a good method.

I can think of a few organized ways of keeping track of it (array of bool's, for example). But, I'd have to test the efficiency of that method. I think your method of simply increment on creation and decrement on deletion if the most recent would be best.

That's most direct way and in theory should work if the Sprite objects are deleted in the reverse order that they're created. That's fine most of the time. However, if I created a vector of those objects and randomly removed some out of the middle then I have to consider gaps in the numbering. At that point I'd probably have to check from the nextSpriteNumber down to the current one being removed and if GDK doesn't know about it, decrement nextSpriteNumber. However, if I invalidate one that I have later need for....

Life is so unfair.

Well, if you're OK with a little extra work on the CPU, I think that something like this would be good:



Then, when a new object is created:



And at the deletion of an object:



Then, for good practice, have some method of using all the false one's when you've reached the max of 65,000 or so.

Hmm... Lilith - You can RESERVE ID's for the sprites naturally and then delete when not in use - and recreate on demand - so they are only instantiated in DarkGDK while in use. This might cut some lost rendering time for you.

I have a 2 prong approach to ID creAtion - not neceaarily relevant - and definately not perfect. Let's say I have a id range from 1 thru 200 id's. First time through - my sprite class just keeps incrementing a static counter ... starts at 1 and keeps going until it hits 200. This is FAST as heck. ONCE it rolls though - a flag is set to indicate the roll has occured. Once the roll has occurred - things can get a bit slower because now it loops through the ids (from the last valid one it used+1) and tests if the sprite exists - if it doesn't it uses that ID, if not it loops until it finds one or does a full roll from starting point until it wraps back to said starting point - in which case it fails.

Dunno if this is useful blabbing but could be.
--Jason

I think it's just a matter of choosing when to start rolling through.