importing images

Well first off, import image crashes construct. whilst import frames in animator does not, which is strange, but anyway i am unable to import a 6400 x 4800 picture into construct, because it becames really slow, actually after i import it, because its rather okay until i delete the first empty frame, and i can barely alt delete and shut it down.

Does your gpu even support 8192x8192 textures?

First of all why would you have 6400 x 4800?you'r probably doing it wrong!

Second if you must have that image at that resolution then split it up into parts

Also be carefull about you vram which is your gpu memory!

This is a common error for non-programmers.

You cannot expect to load images that size and have the game run smoothly.

Most graphics cards will reject images above 2048x2048.

Whilst some of the newer ones will accept 4096x4096, I'm sure very few will accept 8192x8192.

If you're wondering why everyone's talking about 8192x8192 when you quoted 6400x4800, the image will be scaled up to the nearest power of 2 value in the graphics card.

Use Google to find tutorials on tiling larger images.

It's one of the most important aspects of game design, and you need to be aware of how much VRam you're using.

Krush.

Well, mmf2 imports large images without any problems, and actually without hardware acceleration. and if it's a backdrop object it doesnt affect performance aswell. But i havent noticed anything like that in construct. I did tried adding the picture tiled, but then i had a problem because the tiles at the edges were a bit off...

"mmf2 imports large images ... without hardware acceleration"

The point is that because it is hardware accelerated, you are constrained by its limitations

For titling the image use grid alignment

Well, mmf2 imports large images without any problems, and actually without hardware acceleration.

As adrix has already pointed out, it's a hardware limitation.

There's isn't a graphics card in the world that has unlimited VRam and bandwidth, and these things need to be taken into consideration.

You can't just throw any amount of data at the hardware and expect it to deal with it every tick.

MMF2 isn't using magic to load the image you talk about.

It's just not using any hardware acceleration, so it's not limited by the hardware.

Resource management is a basic requirement for game programming.

You really should do some research on it.

I'm sure there's plenty of info out there for the beginner.

Maybe someone will post a few links for you.

Krush.

Break the image up into a grid of smaller parts - about 1024x1024 or 512x512 - and tile them. Hell, only some of them will be visible, so only those are rendered and you get better performance.

I'm not going to do the typical assuming that so many do here about people's experience, because I don't know anything about anyone's experience. I've been coding in C for a long time now, and Construct is not exactly like programming in a language at all, so you could be the most experienced coder in the world and still be confused to no end by Construct. I know plenty of seasoned professional coders who fall right into that category who want nothing to do with event-based programs out of frustration.

Anyway, Skyhunter has raised something that should be examined respectfully. In Construct in a few of my projects, it's had trouble loading a few mere images in "Run Layout" totaling just 200 KB's each and my computer has more than enough power for Construct and is in tip-top shape. I've then taken the same images into other programs to test it, and they loaded quickly with no problems. It's not simply a hardware issue, there is something deeper. I put this in the same bin as those who've had trouble getting the 360 controller object to respond, and that was an issue that the community denied and blamed on the user (check it on search) with such gems as "you don't know programming that's why you can't get it to work" etc, the typical bull know-it-all's say around here. However, it was finally found as a problem and as you can see in the Changelogs, it was addressed by the developer.

The point is, things that are working on some machines aren't working correctly or at all on others. Some people have inferior machines and it's working fine, and then yet on superior machines it's not. It all needs further examination into why that's happening rather than the typical community dismissal.

RaymondHooks

I don't know about your problem but if you think it doesn't run well post in another topic or even further detail it here if you think its related

However in Skyhunter case, the problem is most likely the hardware limitation and if so it has nothing to to do with software

Skyhunter can you post what your gpu is?

ati radeon hd 3870 512mb gddr4

but anway it doesnt really matter, i thought that some object in construct might act as or similiar to backdrop in mmf, I did try the tile thing but its a lot of work setting them next to each other and everything so they form the final picture...

I did however thought about not using the picture but to code the stars and import single objects for space stuff, like distant nebulas and planets. But it would be much faster and simpler if i could just import the picture.

That's strange as your gpu does support 8192x8192 textures(well yours anyway) so in theory it should work

Just what type of image are you trying to process anyway?(might help to give some point as to spread it out)

It's an image of space, i v made in painter, its in jpeg format 6400x4800 resolution. And i can only import via animator import frames. Because construct crashes when i click the import button for importing images in the picture editor for some reason.

hardware accel is a double edged sword

it allows for mass transformation and modification of images with little slowdown, and many images to be rendered, aswell as putting much less load on the CPU, but super large images arent easily handled since it has to work with the GPU hardware.

importing images in excess of even 2000+x2000+ wouldn't be a good idea in any case, since your limiting the amount of other stuff you can have, and it swallows up alot of rendering time. your also limiting the number of people who can play your game.

Every rendering method has its own advantages, learn to use them as best you can. in this case, scaling "nebula textures" and placing many sprites instead of a large image would be faster and better.

^yeah what quasi said, plus you have to remember everything is saved internally as png, and then uncompressed at runtime.

So unless its possible to make an object that allows you to render differently (probably not in C1), then splitting things up is the only option.