Local variables

a 2x2 png takes up 148 bytes. i think 2x2 is the minimum that can be loaded into vram, since its the smallest multiple of 2.

i seriously doubt 148 bytes is going to make your game have any loss in performance, the implementation of layout variables would probably use more power than the sprite anyways.

would a game really need that extra space?

Aeal i think youre a lil too paranoid about performance in that sense. if you really wanted to be making youre games that effecient why even use construct, technically its making youre game alot slower than it needs to be? why not use C++? well you dont really have to, do you?

The point was to save the Vram not to improve performance. I don't make games in C++ because I dont have the coding ability to yet. And What is the point of wasting those bytes? When I could go into the SDK uncommnet a line or two and copy and paste some code compile and I have my own solution. As I said before if you dont like the plugin I dont give a shit. I made it for me to use in my games I dont care if you use it I just uploaded it for people who would like something like that.

Please don't add unnecessary ACEs to "System" object. Construct needs compromise between number of ACEs to master and their power. The more there are ACEs, the harder is Construct to learn.

First of all they are your Basic set, get, compare, add, Subtract, aces same ones every other variable has. If you are too stupid to know what those do then you should not be making games. And if you cant remember what they do ITS IN THE NAME! READ IT!

But seriously, what's a small 2x2 or even 4x4 sprite going to do? heck, use a text object with no text! (or does that use vram in some weird rendering way?). You guys can't seriously be annoyed at using 148 bytes of Vram? That's BYTES! One nice fat texture in your game and those bytes just fade away up in the memory useage that one texture takes. There's practically no point to layout variables. Why not just use a global variable and tell it to change on the start of each layout you want it to change in?

First they wont fade away the ram will still be used. I know it maybe negligible in smaller games but Ive been working on a game where every bit of vram counts. and why the hell do you care if I make a plugin that dosent draw to the layout and uses private variables I never said you had to use it. To me it helps keep my layout clean and organized. Yet again I dont care if you use it. if you dont like it then dont use it your not hurting my feelings.

Lastly layout variables would be useful. you all said you have some way of getting around not having them and thats fine. but how can you say they are not useful when you all have a way to do that exact thing? The right wording that you are trying to come up with maybe that they are not an important feature to add right now, but don't go saying they would not be useful when you are doing the same exact thing.

Now, now, calm down, everyone is entitled to their opinions. There is a little bit too aggression going on in here.

If Aeal wants to develop plugins for his own uses, sure, no problem, that is what Construct is for! If he wants to suggest layout variables as a part of Construct base, well, that is an opinion as well. Even if we disagree, we have to remind ourselves that jousting each other's heads off is hardly productive. He developed his own method, fine and dandy, it is his game.

What features to implement into Construct, however, is the developers' word that is final. Obviously we can see that they see this as an unnecessary feature, since there are many other ways to achieve the effect.

Also, there are objects that don't use up any VRAM and can contain private variables. Namely Text object. You could use them for debugging, too, for example to show a certain PV in runtime; in release we just turn it off.

Or, better yet - you could use those text objects for more than one purpose; show the title of a chapter, like "Chapter 1 - The Awakening" in a neat way during transitions, but they'd also store variables for that layout! No wastage at all.

Just some creative thinking

Since Text needs place in memory to render its text I'm quite sure it also needs some VRAM allocated.

What Aeal does with his plugin in nothing of my concern. However, I don't like the idea to have this 'local variables system' integrated with IDE (meaning they'll go into 'System' ACEs or they'll be included as standard plugin in every new Construct build).

Aeal your behaviour is clearly irritating now. Consider changing it, because it's troublesome to have conversation with people calling others "stupid".

I didnt call you stupid you may have misunderstood my post.

I mean that if you (As in the user) do not understand what basic Set, Get, Add, Subtract, Compare does then you should not be making games

a 2x2 png takes up 148 bytes. i think 2x2 is the minimum that can be loaded into vram, since its the smallest multiple of 2.

Hey Quazi, MATH just kicked in!

2^0=1

2^1=2

2^2=4

etc.

Math doesn't tell a thing about how many memory is allocated for initialization of object in VRAM and how much single pixel needs bits to be represented.

Aeal now try to figure out if I know what does these things mean .

> a 2x2 png takes up 148 bytes. i think 2x2 is the minimum that can be loaded into vram, since its the smallest multiple of 2.

>

>

i dont think ^0 can be used. i could be wrong though.

thats why i said "i think" 2x2 is the smallest

empty project, the object in question

+ 1 text object displaying vram remaining

hash table with 10 keys

2522873856 k in vram

12576 k in task manager

10x1x1 array

2522873856 k in vram

12556 k in task manager

0x0 sprite with 10 entries (invisible and off screen)

2522873856 k in vram

12528 k in task manager

0x0 sprite makes 0 impact in vram when invisible

I did this twice, accidentally erased my post the first time

and the other time the sprite used the most ram in task manager

with the array in second. I guess it doesn't make much of a difference

it's all a matter of convenience

unless you plan on having 100s of variables, which I do

but then, you'll probably need an array

or a bunch of sprites storing xy info anyway

I think it's low priority,

but I don't think it's worth getting all aggressive about

also, I get his point

it is a workaround. it's no big deal

it's not like construct is full of em

but it is.

putting a text object I don't need in a project in order to store variables locally

is a workaround

it's not even a pain in the ass, it's almost as simple as having an object made for it

but it is a workaround.

not really a workaround, it gets the job done exactly how youd want it, calling it a workaround is just like saying (i want an object variable object, which i can make a container of the object its going to be used for, then use it for PV's. i dont want to use a sprite for it)

its the exact same thing. it wont change a thing if you use a sprite, its not even an inconvenience.

whats wanted here is variables which can be used on a per layout basis, this accomplishes this task, it isnt a workaround, its a solution.

We're just going around in circles here, and everything that can be said on the subject has pretty much been said, on both sides of the issue.

This is just belaboring the point.

Yeah, I think this thread isn't productive anymore since it's way too heated up. There'll always be topics where one group of people thinks solution A is better and the other group pledges for solution B - in the end, it's not worth getting all mixed up about that.

Personally, if I know the app has global variables, I sorta assume that we'd also have local (the better term actually is layout) variables. Getting to the solution that I'll have to use a buffer sprite and use its private variable would've taken me longer to figure out than having layout variables natively built into the app.

It doesn't really matter right now since we get the same result using both ways, so let's not get all fussed up about it anymore. There are more important things to talk and research about

I think this argument is completely ridiculous. As I said before, it won't happen before 2.0, but I think layout variables are a good idea and we can fairly easily implement them next time around for 2.0 without occupying much time. If you don't think they're useful you can completely ignore them. If you like the idea you get the benefit of having them.

In the meantime using a small sprite is a perfectly acceptable workaround. The VRAM argument is irrelevant. The runtime could easily allocate 16mb of VRAM internally depending on what you're doing. Having a 32x32 sprite to store some private variables will occupy about 4kb of VRAM. It's like trying to save 10 CPU cycles on an event when the object selection routines use 10s of thousands of cycles, or a simple CPU branch mispredict might take 20 cycles. Have some perspective!

To add layout variables right now would be to add another layer of arbitrary variables; in 2.0, there will be just 1 place to set up variables, and there it can be decided if a variable is of global or layout scope.