Construct Classic is "officially" dead?

New releases and general discussions.

Post » Sat Feb 04, 2012 9:26 pm

[QUOTE=Qwary]I have no more than 4 fps. What am I doing wrong?[/QUOTE]
You demand too much of your hardware. Even in "Rage" or "Battlefield" or "Skyrim" and the like, you will never ever see 1000 objects of 4096x4096 with a texture of the same size. It's just not the way it's working.

[QUOTE=lucid]interesting. I'm getting about 15fps with the sine behavior on all of them, and about 30 without it. I have no idea why one png would render slower than another, especially that much slower, but perhaps one of the more knowledgeable folk around here can enlighten us.[/QUOTE] I'm getting 15 fps, too. It's not a matter of png rendering (the textures are on the graphic card's VRAM in a simple RGBA format, no png/jpg/etc anymore), it's a matter of different test settings. A graphic card has much more work to do if the viewport is larger. If you just half the width of the window from 1280 to 640, you will see that the framerate will instantly go up. Also, the hardware may differ. While my GTX460 Hawk is relatively powerful, a GT7600 is not. This will also result in different framerates.

[QUOTE=lucid]In any case, even 30 fps with a workload that insanely exaggerated proves the point that there's more than enough power if you take the time to learn how to use it. You should never design a game that way with 1000 4096x4096 sprites on screen, this isn't just in construct.[/QUOTE] Absolutely correct. And it is a point that was explained some hundred times before now: If you try to use your hardware in a way it isn't designed for, you won't get what you want.

[QUOTE=lucid]As far as 5 shaders and it's contribution to slowdown, I don't know much about them, but I suspect the games that look great use more complex shaders, not necessarily more shaders. CC is limited to PS2.0, perhaps this isn't what you'd want, but I'd suspect most 2d titles, including AAA titles don't have multiple shaders running at all times.[/QUOTE] That's correct as well. Most games (incl. AAA) will make use of 1 post process effect, that may run at all times. All other effects are placed carefully and the design of the game will factor in the use of effects, so that the amount is always as low as possible.

Some general informations:
1) Pixel shader
A pixel shader is an algorithm that runs on the gpu side and calulates every pixel it gets passed. Modern cards have shader units. They do whatever task is needed, vertex, pixel, even other tasks. The more units you use, the less gpu power for all the rest of the work, that needs to be done.
If you use a pixel shader on a 4k texture, then that shader calculates 4096x4096 = 16.7 million pixels per tick. That's 1 billion pixel calculations per second at 60fps. Now do this on 1000 4k textures and you have a quadrillion of pixel calculations per second, just for one pixel shader!
Of course, that's not the way, shaders are used. Instead, in 3D games, low res copies of a hires texture are made. For example, the hero may have a 4k helmet texture. But currently on screen that helmet is seen from a distance, so that it's only a couple of pixels big. Instead of the 4k texture, a 128x128 copy is used and sent to the pixel shader. You don't see the difference as it is so small, but the graphic card now only needs to do 0.9 million pixel calculations per second, instead of 1 billion.
In CC you should adapt that technique. For example, if you do a color correction on a 4k texture, but your game window is only 1280x720, then you are wasting processor power. Instead, attach the shader to a layer. The shader will now calculate the visible 1280x720 pixels and not the full 4k texture.
Also shaders should be deactivated, if their effect is not to be seen. For example, if two sprites lay one over the other, so that the lower one is completely covered, you don't need the pixel shader applied to it.
I'm sure there are many other optimizations I'm currently not thinking of, but the simple message is: Think smart, when designing your game.

2) Texture sizes
There are many, many cards out there, that are still optimized for lower res textures, like 512 or 1024. They do support 4k textures, but have a hard time with them. Consider that, when designing your game. Also, even backgrounds are not just one huge texture but composed out of many smaller ones. Have a look at this image: Whispered World
It is not one huge texture, but at least a dozen of smaller ones, carefully layered. You have to adapt your idea to the technique you use. If you are working with 3D optimized hardware, you need to split your creations into smaller textures and compose the game's graphics from them.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Sat Feb 04, 2012 9:53 pm

So far virtually every project I've worked on has bottlenecked on logic and not graphics. It's hard to tax the GPU without doing stuff that is obviously stupid and wasteful unless you're REALLY pushing the graphics that hard. I could be happy with CC for a lot of stuff if it wasn't for the fact that what I made was permanently tied to windows. Bugs in the editor aside, I'm extremely happy working with it.

So one related question and one unrelated question. Lucid, can you give any sort of feature/fix previews? Since I'm deep in a project right now, knowing what changes might concern or benefit me would be nice so I can plan accordingly.

Also unrelatedly but since we're posting about bugs in CC, what steps can I take to prevent crashes when switching layouts? I remember reading a lot on the topic but can't quite find any. Those are a set of problems I'd like to stamp out.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Sat Feb 04, 2012 9:54 pm

[QUOTE=tulamide]
[QUOTE=lucid]interesting. I'm getting about 15fps with the sine behavior on all of them, and about 30 without it. I have no idea why one png would render slower than another, especially that much slower, but perhaps one of the more knowledgeable folk around here can enlighten us.[/QUOTE] I'm getting 15 fps, too. It's not a matter of png rendering (the textures are on the graphic card's VRAM in a simple RGBA format, no png/jpg/etc anymore), it's a matter of different test settings. A graphic card has much more work to do if the viewport is larger. If you just half the width of the window from 1280 to 640, you will see that the framerate will instantly go up. Also, the hardware may differ. While my GTX460 Hawk is relatively powerful, a GT7600 is not. This will also result in different framerates.[/QUOTE]
oh right, I meant because I had done a test with a different png of the same size, and got a much higher framerate. not sure if there's some optimization done for unvaried textures on my card(hd6970), but in the faster test I was using a solid red square of 4096x4096. I even tried lowering the resolution of qwary's test, but it didn't come close to matching my original testlucid2012-02-04 22:12:49
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Feb 04, 2012 10:08 pm

[QUOTE=kayin] Lucid, can you give any sort of feature/fix previews? Since I'm deep in a project right now, knowing what changes might concern or benefit me would be nice so I can plan accordingly.[/quote]something seems weird/premature about posting the actual changelog before the release, but I'll give a general overview. a few runtime/plugin performance/memory-leak fixes, some nonperformance related fixes to several plugins like shadowcaster, drag-and-drop, panel, xbox360controls, platform behavior(i think that's all of them), a few system expression/plugin expression fixes. one addition/one fix to the sdk, and a handful of new additions to various plugins and the runtime - one or two of which may be a big deal to some users, as they've been requested for a couple of years. personally, these last ones are the ones I'm most eager to see released, having been one of those who requested them. :)
[quote]Also unrelatedly but since we're posting about bugs in CC, what steps can I take to prevent crashes when switching layouts? I remember reading a lot on the topic but can't quite find any. Those are a set of problems I'd like to stamp out.[/QUOTE] this I can't comment on. all the projects I've ever worked on used a single layout. but I have heard a reoccurring theme with regards to not crashing while switching layouts, which is : don't use transitions.lucid2012-02-04 22:17:28
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Feb 04, 2012 10:20 pm

[QUOTE=lucid]oh right, I meant because I had done a test with a different png of the same size, and got a much higher framerate. not sure if there's some optimization done for unvaried textures on my card(hd6970), but in the faster test I was using a solid red square of 4096x4096. I even tried lowering the resolution of qwary's test, but it didn't come close to matching my original test[/QUOTE] Hmm, I couldn't reproduce it. I created a 4k .png, solid red, with paint.NET, then recreated the example from scratch, window 1280x720, layout 20000x20000, same events. In result I had the same 15fps (and btw it didn't make a difference if sine behavior was applied or not, so I guess your cpu is a lot faster. Well, my amd cpu doesn't have a level 3 cache, so...)
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Sat Feb 04, 2012 11:08 pm

hmmm... no, those are about the same results I'm getting now regardless of the texture, must've made a mistake somewhere. I definitely was using 640x480 in my original which runs at just under 40fps for me now. Same here as well, not making a difference with or without sine behavior not sure what I did. either way. moot point with all the rest discussed.

On a side note, I'm running AMD as well, 3.4 phenom2 x4 965 deneb BE. Sometimes when testing caps, repeated runs get 40 fps less than the usual run, maybe I got lucky and had it work backwards that time?

more likely I forgot a 0 at the end of something on my first testlucid2012-02-04 23:15:02
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Feb 04, 2012 11:32 pm

Is that all with, or without per-pixel?
Image Image
B
161
S
48
G
90
Posts: 7,347
Reputation: 66,749

Post » Sun Feb 05, 2012 6:35 am

If you cannot make a good 2d game in Construct it's simply your fault. One can only ask so much of a machine.. "further development" as you say, is pretty much just bug fixes at this point. Construct is pretty mature and powerful.

On the topic of crashes when switching layouts, that has to be the next thing on the bug list. This is the one flaw holding classic back. I'm sure this bug has to be some stupid little typo somewhere, like an array out of bounds or something.Davioware2012-02-05 06:37:16
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620

Post » Sun Feb 05, 2012 8:13 am

is there anything specific anyone knows about when the crash happens? are there a specific set of circumstances that cause it to crash? is it only with transitions, etc. I'm not sure if I'll be able to figure out what's wrong with it, but I'll definitely take a look when I get a chance. Also, if someone could make a barebones cap that causes the crash, even if it's just a few events, it would be helpful.
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sun Feb 05, 2012 7:25 pm

I get it rather randomly while testing my game, either when the player dies (and the layout is reloaded) or when occasionally switching. I haven't noticed any patterns, but I know smashing the Q key to restart for a minute almost NEVER makes it crash.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests