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.

Code Snippets / [DBP] Object Stacks (from newsletter)

Author
Message
Lazlazlaz 1
19
Years of Service
User Offline
Joined: 18th Sep 2005
Location: England
Posted: 5th Jan 2009 02:29 Edited at: 5th Jan 2009 02:30
I have no idea if this is how Steve (or Ian who suggested the idea to him) would implement this, but after reading the newsletter I thought I might give it a go.

Seems like it could be useful considering my last (and now current again) project got bogged down in keeping track of object and image numbers.


So you start off by creating your Unit/Enemy/Whatever udt and an array declared as that type.

Then create two more arrays to hold the 'available' and 'used' object numbers. The 'available' array has a size of the maximum number of objects possible in your game, and the 'used' array is emptied.

Whenever you want to create a new object you call the 'object_create()' function, this returns the new object number which is stored in your unit/enemy udt array.

When you are finished you just call the 'object_delete(object_number)' function.





Sorry this code can't be copy-pasted into DBP and run, but I hope it helps.

If anyone has any suggestions on improvements or different methods, please suggest them. I'm new to this technique.

As with most people I jump around which projects I work on and which I drop for a while.
Currently I'm back working on Sioux, a Hollywood Western RTS.
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th Jan 2009 00:26 Edited at: 6th Jan 2009 00:26
I see an issue with your code - you are using ADD TO STACK. I know this seems like a command made to fit the design, but unfortunately it's not!

My quest started when I realised that dynamically resizing arrays can become a huge problem. So I created arrays that are big enough to deal with all of my entities (not just objects, but a mass of different sets of data). The few Kilobytes taken up by these arrays isn't worth worrying about.

You can see the problem in this thread, and how the stack system fixed it, and increased performance by 400 - 500%!

This may also help to understand the system. It's an extract from my Wiki I keep for my projects, so that when I look back I understand exactly what I did and why



Attachments

Login to view attachments
Lazlazlaz 1
19
Years of Service
User Offline
Joined: 18th Sep 2005
Location: England
Posted: 6th Jan 2009 02:15 Edited at: 6th Jan 2009 02:18
So instead of using the built in DBP stack commands it is better to create static sized arrays with a related variable that points to the last element of interest, and not delete or add any elements to the array.

I'll take a look at IanM's codebase entries on stacks


edit: ok now im a bit confused.

IanM uses 'add to stack' in his codebase entry, but you say you use his stacks method as well as saying not to use 'add to stack'...

As with most people I jump around which projects I work on and which I drop for a while.
Currently I'm back working on Sioux, a Hollywood Western RTS.
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th Jan 2009 11:50
I haven't seen Ian's codebase entry. But is he using this if your array gets too big? Or to add a block of elements at a time?

I tend to start with 1000 elements (it suits my project). The code also checks for the need for more than 1000 elements, and expands it by 10% each time it needs more. This is far more efficient than adding one element at a time.

Behind the scenes, every time you expand an array (ADD TO QUEUE, ADD TO STACK etc) it must copy the whole array of data to a new memory location and add the extra memory for the new element.

So to add 100 array elements at a time is better than adding 1 element 100 times, and with probably no more processing overhead.

At the time Ian wrote that code, he will not have been aware of the memory fragmentation we discovered recently, caused by repetitive expanding of arrays.

Lazlazlaz 1
19
Years of Service
User Offline
Joined: 18th Sep 2005
Location: England
Posted: 6th Jan 2009 12:51
Ok, cheers BatVink. It seems you have saved me from a lot of problems with my program.

As with most people I jump around which projects I work on and which I drop for a while.
Currently I'm back working on Sioux, a Hollywood Western RTS.
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th Jan 2009 12:55
No Problem. Bear in mind that I exaggerated the problem ,so it's not necessarily as bad as it first looks. I have a test program that runs these things to destruction to make sure they stand up. In this example, I tested to see what would happen if I created and destroyed 200,000 objects. It started to fail very quickly though, so it was worth doing, and worth updating the methods.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th Jan 2009 14:30
The examples in the Codebase are a very basic look at how stacks, queues and lists work in DBPro. They are NOT the way that I use them now when I'm looking for speed.

If I want a stack, I'll use the array as a list and use the built-in pointer as a marker of the top of the stack.
If I want a queue, I'll use the array as a list, using the built-in pointer as a marker of the end of the queue and the ROTATE ARRAY command from my plug-ins to shift items from the queue.

There are lots of other little tricks I use too, and all of them aimed at one thing - to avoid allocating memory within arrays as much as possible. As long as you don't try to expand an array, arrays don't allocate memory.

Login to post a reply

Server time is: 2024-11-25 09:12:15
Your offset time is: 2024-11-25 09:12:15