Local variables

New releases and general discussions.

Post » Thu Apr 16, 2009 11:24 am

Just to clear this up:

Aeal: Your plugin isn't really well designed. It's the same thing that deadeye suggested, it's just an object with private variables - so that doesn't make a lot of sense. I could use a sprite, use my own icon and fill it with a private variable.

What I was thinking about is a local variable that's based on your layout. So you'd be able to click on your project and set global variables and you'd be able to click on each layout and set local (layout) variables.

@Rich: A workaround is not just something you do in order to steer around a bug. A workaround is also a solution you use, because a certain feature that you want is not implemented in the application yet - so you come up with your own little idea that might work, cause the program is complex enough.

I'll give you one example - In Maya, you were never really able to store assets properly. So people just started creating 'groups' and deleting all the shit in it, so they ended up with a completely empty node and filled that node up with custom attributes (like private variables) - tada, we got an asset node.

Now, in a recent release, Autodesk actually created a feature called 'assets' that handles this for you without the workaround that's using empty nodes and it's a lot more comfortable because it aids the user as well. It's easier to set-up, it's easier to organize, it is its own entity specifically designed for a certain task that users used all the time anyway - but they had to fake a method up until that point.

We have global variables. If I have 300 levels and I want to use a variable for each level to control a certain event, I could just use a layout variable and wouldn't have to clutter up my global variables.

[quote:31h9775w]The only caveat is that initial values for hash tables/array can't be set; this can be remedied via some very simple additions to the SDK. If a dev wants to take it on I can send them the sources for either.[/quote:31h9775w]

I'd fucking love that!
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Apr 16, 2009 12:00 pm

[quote="thomasmahler":2ew8xbx5]Aeal: Your plugin isn't really well designed. It's the same thing that deadeye suggested, it's just an object with private variables - so that doesn't make a lot of sense. I could use a sprite, use my own icon and fill it with a private variable.[/quote:2ew8xbx5]


Nope its not badly designed, it is exactly what I wanted. If you bothered to read through the other posts you would have seen I have no problem with using a sprite to hold "Local variables" for now, I just didn't like the thought of wasting Vram. And since I very rarely share caps of a game that I am working on with people I wont have a problem with the "Plugin not Avalible".
Its exactly what I wanted. If I can easily make it easier to link them to the layouts then fine i will but as for now its an easier solution for me to open the sdk set a few properties and compile my own solution. I really dont care if any of you think its a bad Idea then don't use the plugin, I made it for myself and I just decided to share it with you if want to use it.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Thu Apr 16, 2009 12:05 pm

The SDK can't do what I think some of you propose, which is to have the variables in layout properties.

Also, there is no definition I can find of workaround which doesn't mean working around a problem or broken feature; in this case there is neither, as better solutions than the supposed 'workaround' exist :P.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

Post » Thu Apr 16, 2009 12:10 pm

Aeal: It's cool, didn't want to piss you off. I just thought your plugin isn't what you suggest on the thread. I always thought you were talking bout layout variables.
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Apr 16, 2009 12:40 pm

The only way we can really get the feature that Im talking about would be to build it into the IDE. Since there is no point in modding the IDE I made a plugin that will do the same thing without taking up vram
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Thu Apr 16, 2009 1:07 pm

[quote="thomasmahler":1qf6vs9d]Aeal: It's cool, didn't want to piss you off. I just thought your plugin isn't what you suggest on the thread. I always thought you were talking bout layout variables.[/quote:1qf6vs9d]

Yeah, that cannot be done with the SDK...
B
2
S
1
G
4
Posts: 156
Reputation: 1,612

Post » Thu Apr 16, 2009 8:10 pm

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?

This isnt a workaround, it really wouldnt be all that usefull to have layout variables, they're a very negligible feature, i much rather the devs spend times fixing bugs than implementing things which have a very small advantage (148 bytes of vram) over a technique extremely easy to set up.

not that its a stupid idea, but having them really has no strong advantages.
B
52
S
7
G
6
Posts: 1,945
Reputation: 7,610

Post » Thu Apr 16, 2009 8:45 pm

Not in the way this plugin works - cause it's essentially just a sprite with a private variable, but without the memory footprint.

But I still think it'd be cool to have a local variable that's based on layouts without having to use sprites as buffers.
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Apr 16, 2009 8:58 pm

The first problem with this topic is calling "using Sprite's PVs" a workaround. This is so intuitive and easy to handle local variables that it doesn't even deserve to be called "a workaround".

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.

Quazi I hope you don't get serious Aeal's talking about "saving VRAM". He can't be serious ^^.
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Fri Apr 17, 2009 3:10 am

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?
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests