Layout Size and Big Images

You know, i dont quit get it.

i know its like the basics but i cant find a straight answear.

In Construct, we are allowed to have a really big Layouts/Levels, but at the same time - we are discouraged to used big images as a backgrounds. Then whats the point?

I am aware that there must be a proper method of doing big levels with big backgrounds, but how?

If i have a big layout with huge image(s) the VRAM will choke like lungs-cancer. If i slice the images into smaler ones - then the performence impact will come from number of objects.

I havent bumbed such issue with RPG Maker so i am asking.

And its not a big deal if were talking about repeateble textures - for that theres Tiled Sprite obj - fine. but what if i have a beautiful, detailed, high resolution BG image - which i worked hard to create in PhotoShop. What then? How you manage with this issue?

I am asking because the first thing that hit me in Construct was how big the layouts can be. and i thought - wow! finaly i will be able to use huge seamless areas, instead of spliting them into lots of small ones. I mean, come on - whats the use of a huge layouts if they have to remain empty for the sake of performence?

I will be very greatful if you provide me with the method that my eyes and brain are missing.

As always, i presume itll be very obvious. But still it slips my grasp.

A few methods:

• seamless layouts are made of reusable graphics that are repeated where needed
• big, huge, humongous drawn background? No problem, research parallax scrolling - move the background at very low rate, say 0.5%, and the background will move very slowly compared to the player on much, much bigger layout.
• did I mention reusable graphics?
• who needs background, anyway? paint it black and you have open space. Spawn some stars when in view. Voila.
• proximity preloading of graphics (load them when you get within range, they will be rendered when you get on-screen) - most seamless world games use this in combination with, guess what? Reusable graphics!

Mipey

I think you forgot to mention 'Reusable graphics'

[quote:10v9ia4j]seamless layouts are made of reusable graphics that are repeated where needed

as i said

[quote:10v9ia4j]And its not a big deal if were talking about repeateble textures - for that theres Tiled Sprite obj - fine.

i am already aware of that

[quote:10v9ia4j]- big, huge, humongous drawn background? No problem, research parallax scrolling - move the background at very low rate, say 0.5%, and the background will move very slowly compared to the player on much, much bigger layout.

but what if he wants to zoom? the pixels will hits he's face.

I know how to simulate big layouts by playing with the speed and scrolling. The problem are maps which ive made beautiful in photoshop. Think: hand drawn or painting. theres no pattern there.

[quote:10v9ia4j]- did I mention reusable graphics?

yup =)

[quote:10v9ia4j]- who needs background, anyway? paint it black and you have open space. Spawn some stars when in view. Voila.

well for space its not that a big deal.

BUT.

look at this:

<img src="http://imgsrc.hubblesite.org/hu/db/images/hs-2007-01-j-web.jpg">

and then compare it to that:

http://imgsrc.hubblesite.org/hu/db/imag ... es_jpg.jpg

another note: the game takes place not only in space void. A huge part of the game, if not the main, is planetary exploration. and for that purpous i have created loads of preety planet maps such as this:

http://img97.imageshack.us/img97/2548/texu.jpg

[quote:10v9ia4j]- proximity preloading of graphics (load them when you get within range, they will be rendered when you get on-screen) - most seamless world games use this in combination with, guess what? Reusable graphics!

hmm, that would actualy help? and by preloading you mean "visible"/"invisible" toggling? or dynamicly creating/destroying the slices objects?

i know the best option would be to take all the parts ingame and arrange them with Construct as objects. But this option cant be used by me as i use 2nd party programs to render such images.

for special effects i have very advanced and complex particles program, for terrain i have fractal based program. thats why i really cant deattach parts of the image like landmasses, islands ect

another problem is: if i will use slicing method i will end with hell load of objects trashing my objects bar. to avoide this i would need to make one object with and make the parts of the image be a seperate frames inside this object. this way or another - lots of lots of ant's job.

shame there is not such plugin that would "break" the object into smaller ones. or at least - some kind of folders in Construct object bar. with a complex layout it gets very messy in a very short time. being able to arrange them in folders would make it so much readble.

There are ways around everything

I'll just leave this here.

http://dl.dropbox.com/u/666516/finalfrontier.cap

If you haven't already, I'd highly suggest downloading the perlin noise plug.

http://www.scirra.com/forum/viewtopic.php?f=2&t=4836&hilit=Perlin+Noise+plugin+Arsonide

(required)

So I'll be annoying and repeat/ask...

Is it really impossible to use a big picture as background without harming performance? I know I once tried it in RPGVX where I inserted it as a parallax background.

Although I admit that the example newt posted is impressive (I might consider that solution for some things), what do you do if you want a background like this:

<img src="http://www.brainygamer.com/photos/uncategorized/2007/12/28/odinsphere34.jpg">

?

What if such backgrounds are reserved for smaller layouts, like rooms or small caverns, and then tiles are used for larger layouts?

I guess I could just try it out, but it is still early in my project, so I'd rather not harm it from the get-go (in case the performance isn't harmed until a lot of objects gets thrown on top. In that case it would suck to spend so much time on getting painted backgrounds...)

So I'll double-check with the experts instead.

There's no rules against adding bigger images, you just have to set limits for what your doing.

All you can do is load it up, and see how much vram it takes up, but always be aware of what few steps you can take to save that vram, p^2, etc.

[quote:19shnzum]I know I once tried it in RPGVX where I inserted it as a parallax background.

welcome to the club

call two us persistant jerk but we just cant understand why we can dump like ANY size image into RPG Maker VX as parallelax(or w/e the correct name is) and itll be seen ingame without slightest performence hit.

and yeah that perlin noise look nice but totaly not what i am looking for. such thing i would use with RPVX which had huge resolution and effects limits. ive switched to Construct because all those present days prosperities: high res, shaders, bumps ect and now i am supposed to leave it and go back to visiual '90s? no way.

but yes, i will research that plugin as its quite interesting and perhaps - can be used for something else.

also i think i need to do my own test on the methods and compare the outcomes.

give me a day or two and ill check whats the real diffrences betwen the 3 most obvious methods (whole image;sliced-many diffrent objects;sliced-many same objects with diffrent frame)

and ill repeat myself, as you guys are propably miles more oriented in technicals then i am.

Why RPG Maker has no problem displaying any size images and Construct has?

i mean, come on - RPVX is like lightyears behind Construct, but if it uses some nice method to load such images without problem - why not to implement/mimic it for Construct?

and well, this:

[quote:1rjux65s]proximity preloading of graphics (load them when you get within range, they will be rendered when you get on-screen)

is still a mystery for me.

[quote:3fpppx4z]and itll be seen ingame without slightest performence hit.

There are differences in the way engines handle images. Sometimes they handle better big images, sometimes smaller ones. The core can be optimised to render only the visible stuff or so.

Technically, you can put a huge image in construct, it may work well, depending on the hardware. But using huge background is a waste of both HDD space and RAM. Most of the time, game artists and designers won't do that. For those who want, there are specific engines for it (like Verge, a deutsh one).

[quote:2ycsaadz]The core can be optimised to render only the visible stuff or so.

this would be great in Construct seing like most of the newbies such as myself are desperatly trying to use big images.

Hmm how to put it in an understandable way.....

The reason why you can't drop humongous bitmaps in Construct without a huge penalty is the same reason why you can put a jillion transparent moving objects rotating and zooming at a high screen resolution and still get 60fps. Let's see RPG maker do THAT! (and oh, hi shaders!)

It's called hardware acceleration, and every image you use has to be first loaded into RAM and then transferred to the video card memory, which is limited (currently between 128 and 1024Mb TOTAL).

you will ALWAYS have to work around limitations, with ANY computer system. It's a fact of game development. Please, try to learn the tricks that are selflessly being offered.

(Btw that screenshot: half-size the background, then stretch it. Use one layout per room, load textures on layout startup. TADA!)

I would also point out, that little cap I posted uses like .07 vram, and is (infinitely, almost) scalable.

Even less if you make the tiled sprite 2x2.

Did I mention that you can display that in 3d?

But as Madster said there are always trade offs, less vram, more gpu processing.

so okey ive made an experiment.

ive made two layouts with the same 1000/1000pix image.

first is the whole image second is the image sliced for 100 smaller images 100/100pix each.

results:

Big image:

Vram Target: 3.00 mb

VRAM textures: 4.06 mb

VRAM total: 7.06 mb

Big image sliced:

VRAM target 3.00 mb

VRAM textures: 6.31 mb

VRAM total: 9.31 mb

wth? O.o