|
Josh @ Dreamland
|
|
Reply #1 Posted on: October 17, 2011, 11:38:33 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
We're working on it. Should be done by the end of the week.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #3 Posted on: October 17, 2011, 01:19:56 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I thought it was January.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Post made October 18, 2011, 06:27:44 am was deleted at the author's request.
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: October 19, 2011, 09:13:32 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
ENIGMA uses new for each instance, rather than new[] on several. Normally, you are right; requesting a contiguous plot of memory at once instead of asking 10 times for plots 10% of the size is much faster, but you will only see that overhead, ideally, once per instance on the screen. Destroying an instance and then creating a new one of the same size has less overhead, if I recall correctly.
However, allocation times don't really worry me. If they did, I could come up with a far better way of handling this on systems with large memory and slow allocation (systems with small memory presumably have less applications to serve it to, ergo would be quicker on the draw, I would think).
Basically, what I would do is allocate our own heap up front and keep a journal of available spots. We would then write our own new using new() (by your notation, I guess this would be new()()). Basically, we would take the max size between all objects, then pick a random heap size (Probably of 20-40, but I think it'd be wise to give users a say in this), and allocate a grid that way. The journal would then be populated with available spots on the grid. Allocation would be very fast, and deletion would simply queue up a new slot on the journal. As you can tell, the journal would probably be a queue or stack.
As for room regions, I think I know what you're talking about. In a Metroid game I made once, I needed to deactivate all instances except for those contained in rectangular sections of the room. What I did was create two objects with different sprites, one representing the upper-left corner and the other representing the lower-right. I would place these instances in the room and then use their room creation code to group them. Telling which regions you were in would then be as simple as iterating them and testing a few x > other.x. However, ENIGMA presently doesn't support instance creation codes or instance deactivation, so the point is presently moot. Anyway, is that what you are talking about by regions? The room editor is about to undergo some rethinking as we add the new ENIGMA resource, "Overworld." Feel free to make suggestions on that. I will post a topic with regard to the new resource on proposals; I invite you to either respond there or to create a new proposal topic on the matter.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
MrGriggs
|
|
Reply #7 Posted on: October 19, 2011, 10:08:36 am |
|
|
Joined: Dec 2010
Posts: 128
|
Yeah, by regions I mean a box which you can draw using the LGM editor, then reference this region via its ID (say Region101), and check its co-ords.
Well, how I avoided having to compensate for the posibility of using uneccessary RAM because of having to adhere to one level consisting of a lot more instances than others in my engine, is i made a second number which when the number of instances is reached, another block of "new"s are done on a seperate boost thread, so as long as the scripter/programmer doesn't exceed 50 instances per loop, then it's fine.
That increment number could easily be expanded too.
Sorry if my explanation is rough..
|
|
« Last Edit: October 19, 2011, 10:10:37 am by MrGriggs »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #8 Posted on: October 19, 2011, 10:14:14 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I was thinking just an integer ID from 0 to number_of_regions. See the proposal I just posted, and argue for name.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
MrGriggs
|
|
Reply #9 Posted on: October 19, 2011, 12:11:25 pm |
|
|
Joined: Dec 2010
Posts: 128
|
Not at all bothered by what the regions are called was just explaining how I saw the concept of it, which you retorted as the same thing I was thinking. Just a head's up, there still is problem with frame rate and ATI cards :\. Still trying to fix it?
|
|
|
Logged
|
|
|
|
|
|