Discussion for March update

New releases and general discussions.

Post » Wed Mar 04, 2009 9:27 am

details here: viewtopic.php?f=1&t=2993

Unfortunate to see feb features pushed back, but also understandable. i'm always excited when Construct gets big upgrades that add significant new features. i'm still very confident in Construct's potential as a very powerful and flexible game making tool.

What i'm hoping for is an intermediate 'unstable' build released as soon as the revamped control system is done -- i'm making a multiplayer game designed around gamepads and have been setting aside progress for key parts of the game as i wait for this revamped control scheme. i'm looking to go public with a playable build by mid april, so i'd like access to this revamped control scheme as soon as possible. i know you guys are busy -- i'm just suggesting having the revamped control scheme as one of the top priorities, as i think gamepad support and multiplayer support are both very fundamental.
B
2
S
2
G
4
Posts: 254
Reputation: 1,958

Post » Wed Mar 04, 2009 11:16 am

They haven't really been pushed back per-se, we didn't anticipate releasing 0.99 in February (barring unforseen amounts of time); the renderer's nearing completion, and object folders too, so we're just looking into the new control system and some other stuff, hopefully it's all done in a couple of weeks.

There probably will be an intermediate build to solve some silly issues with the current build, but whether any of these features will be in it I'm not sure.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

Post » Wed Mar 04, 2009 1:00 pm

New Control system with Multiplayer would really be a big change - can't wait to see that happening :)
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Wed Mar 04, 2009 1:16 pm

Rich when you say renderer what do you mean?
B
3
S
2
G
5
Posts: 301
Reputation: 2,302

Post » Wed Mar 04, 2009 1:26 pm

A rewritten renderer so that we can implement V-RAM controls. It's better explained in the February update.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

Post » Thu Mar 05, 2009 12:22 pm

Ah that i see what you mean, seems like some great additions are coming. I can't wait to try out Terminal Orbit, been so so so long coming!
B
3
S
2
G
5
Posts: 301
Reputation: 2,302

Post » Thu Mar 05, 2009 12:41 pm

Indeed :D V-Ram controls in particular are of vital importance to large scale projects, as are object folders.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

Post » Thu Mar 05, 2009 1:41 pm

It'll be cool to see how the VRam stuff will work. Currently, I imagine it like a container, you set the size of the container (vram of your target audience) and just shuffle stuff in and out of there and setup 'load' times accordingly.

Object Folders and - probably even more important - a better way to organize and handle the layouts and layout event sheets would really help for bigger projects. Like, why not put parenting in there? Every layout comes with an event sheet, so you could immediately organize it that way, like:

"Oh, I wanna find my layout 1 event sheet... where is it... ah, yeah, I just press the 'plus' sign next to layout 1 and - ah, there it is!"

If we could do parenting and also have folders in there, it'd really help keeping larger scale projects organized and readable - especially also important if more than one person is working on the project.
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Mar 05, 2009 3:34 pm

It's not possible to control VRAM how you describe. The runtime has no idea which textures you're going to need shortly. It can only guess, and when it gets it wrong, the game will become noticably choppy as it transfers textures to the GPU (it's a slow process). And if there are X megabytes of textures to show on-screen, you need X megabytes of VRAM, regardless of whatever limit you want.

I haven't fully designed how the system will work yet, I'm still working on it, since it's important to get something which is useful and will work well before I start coding. But it'll probably take the form of:
- Layout settings (load and free the layout's textures on an application or layout lifetime)
- System actions (dump all VRAM, dump currently unused VRAM. or cache certain objects for customisation)
- Object settings (load and free object textures in the layout or object lifetime) although this is not as effective a way to do it

If you have any other suggestions how it could be configured I'm listening (now's the time to get your ideas in), however, in short, the user will have to decide how to load and unload VRAM. The runtime can't second guess what your game is going to do, nor can it magically lower the minimum requirements to less than what they really are.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,478

Post » Thu Mar 05, 2009 3:37 pm

The most important thing would be an ability to load textures from resource and dump them at will.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests