Performance penalty when running game in a game using iFrame

Discussion and feedback on Construct 2

Post » Mon Mar 31, 2014 1:07 pm

Ashley wrote:It would probably be very slow, not because there's anything particularly inefficient about iframes, but just from the fact a typical game will use up a fair bit of CPU/GPU/memory, and running several at once will use a multiple of the system resources. Desktops might get by but I'd imagine it'd choke mobile devices.

What are you trying to do? Why are you asking the question? If you want to make a menu in an iframe, it's a very inefficient way to go about it since you get the overhead of an entire game engine just for the menu by itself. It'd be better just to design it in-game itself. However if you're making some kind of arcade, it would of course be better just to run one game at a time!


I have an use-case for you: I'm designing a space game which has two "views": in the first, you control a character and can move around in a tile-based world. In the second, you control a ship in a arcade shooter style. You can freely switch between modes, since you can (and should) walk around in your ship during combat. However, both modes are so dissimilar that programming them is making my layout be a bit of a mess. Separating them in different layouts would be better, but switching between them during the gameplay causes noticeable delays. Also, both "modes" must run at the same time (since they must be kept in sync), even if only one is visible at a time.

Currently my approach is to code two engines and keep them in sync via shared variables, hiding one game and showing the other when appropriate. Is there a better way?
Keep in mind this is a desktop-only thing.
Last edited by Fimbul on Mon Mar 31, 2014 1:41 pm, edited 1 time in total.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Mon Mar 31, 2014 1:27 pm

Designing it all in the same project would be better. Ideally we can improve the tools in the editor to make this more practical. I think the existing feature request for an "inheritence layer" would solve the keyboard issue. Not sure about the other case, but an in-game "sub-layout" view would be a lot more efficient than a whole new instance of the engine in an iframe. That could be quite a lot of work though, so I'm not sure we could do that soon...
Scirra Founder
B
402
S
238
G
89
Posts: 24,632
Reputation: 196,031

Post » Mon Mar 31, 2014 1:38 pm

I think an include layer would be indeed very good.

You mention inheritance -- do you actually mean inheritance in the Object Oriented sense?

I used to work (a long time ago) with a visual language (Digitalk Parts for Smalltalk), and visual components were in essence object instances (not unlike object type instances in C2), and you could freely subclass them, to add or customize specific behavior.

For example, consider having a named (layer/include event sheet pair), which you can include in another named (layer/include event sheet) to add additional objects types and events. Perhaps this makes sense too in C2.

Dan
B
9
S
4
G
1
Posts: 207
Reputation: 1,385

Post » Mon Mar 31, 2014 1:40 pm

Ashley wrote:Not sure about the other case, but an in-game "sub-layout" view would be a lot more efficient than a whole new instance of the engine in an iframe. That could be quite a lot of work though, so I'm not sure we could do that soon...

I'd love to see this, especially if it means we can code inventories/option menus and other complicated things in separate layouts. Would also help greatly with split-screen multiplayer (where most of the logic can be in the "main" frame, and the player's views can be kept in two sub-layouts).
I know you have a lot of stuff on your plate, but +1 to that feature :D
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Mon Mar 31, 2014 1:49 pm

Also, i guess, a HUD would then go into an "inheritance layer" rather than replicate it across layouts.
B
9
S
4
G
1
Posts: 207
Reputation: 1,385

Post » Mon Mar 31, 2014 2:05 pm

The "Inheritence layer" is an old Classic feature. I don't think it really used OOP "inheritence", it was more like an auto-copy-paste the initial objects of a layer to other layers on other layouts. So you could have an on-screen keyboard on one layout, use it on any other layout, and have a single place to make changes.
Scirra Founder
B
402
S
238
G
89
Posts: 24,632
Reputation: 196,031

Post » Mon Mar 31, 2014 2:10 pm

In such discussions I wish you could consider making C2 open source :-)

Enthusiasts could then add features -- offloading work from you guys. But, would it then be possible for you to define a viable business model for yourselves to ensure that all the hard work you put into this is not lost (in a commercial sense) ...

Dan
B
9
S
4
G
1
Posts: 207
Reputation: 1,385

Post » Mon Mar 31, 2014 2:18 pm

grossd wrote:In such discussions I wish you could consider making C2 open source :-)

Enthusiasts could then add features -- offloading work from you guys. But, would it then be possible for you to define a viable business model for yourselves to ensure that all the hard work you put into this is not lost (in a commercial sense) ...

Dan


That discussion topic has been done to death - use search - and is better off staying dead, IMO.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,548
Reputation: 60,440

Post » Mon Mar 31, 2014 2:21 pm

sorry :-), didn't do a search ...

I am quite apparently new to C2.
B
9
S
4
G
1
Posts: 207
Reputation: 1,385

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 5 guests