I've noticed things start to go a bit weird after I increase the play area size past 30,000 pixels. I can no longer use the scroll bar at the bottom of the level editor to navigate properly as it seems to not want to go further than 30,000 pixels. Are there any other problems I should be aware of if I want the play area over 30,000 pixels?
Yes I get the same problem and I just noticed you can't make a quick backgound bigger than 32767 x 32767
Yeah, the same thing is happening to me. One thing I've noticed is that the "background box" object, whereby you can have a repeating background in the distance, will completely konk out (i.e., go black) at around 33,000 pixels. It'll scroll your backgrounds below that, but above that the box won't work at all.
I forget what the deal was with 30,000, but I remember that being a magic number of sorts... I think I was making a huge level and noticed the funkiness...
30,000 is pretty large though...I have found things run smoother having several 10,000 x 10,000 levels and using global rule groups...
Don't forget that such huge levels requires lots of ram. A Bitmap picture with 30.000 x 30.000 pixels requires 6.7 GB of Ram. A Level Background is surely not this much smaller. It's like one big picture
30000 pixels is not big.
Just consider I make a game ,say top down flightsim with screen size of 1024 x 768 , that only gives me a scrolling area of about 29 frames.
Anybody knows why it's only 30000?
btw I don't think anyone has a pc that can create 6.7gb bitmap and still fuction properly.
Creating a level editor, then paste tiles to backgroung in runtime that can surely not use much Ram at all for such a big playfield?
If you create such a game then you might consider not moving the plane but moving the background you'll only need a 1024*768 playfield
I for one am having real problems with this. In my game, you fly a helicopter over land. The game scrolls from left to right. It's not an illusion of scrolling; it really scrolls. So right now the application window is 320x200, while the game frame is like 33,000x200.
The problem I'm having is the land. I want the land to change features and not merely be a repetition of the exact same peaks and valleys, etc.
But how should I insert the land? Currently it is an active object and taking up tons of runtime memory, I'm sure. I had thought it would be better to have the land as a background, but there are problems I can't figure out if I code it that way: when the helicopter collides with just the transparent pixels of a background, that counts as a collision.
So, in the end, the land is a series of active objects each about 6,000 pixels in width stiched together to give the illusion of a seamless terrain.
But it's clunky.
It hardly runs on computers with low levels of rammage.
I need the helicopter to interact with the land, and to be able to assign the land behaviors.
Does anybody have a suggestion for coding this more efficiently?
When using Backdrops: Turn off Colision with Box maybe? Shouldn't collide with transparent areas when this option is off. Click at your backdrop, and have a look at its properties under its runtime options. You may have accidentally activaded it.
Glugmoor, you shouldn't load all the actives (the ones faking background) if you don't need them. From what you say there is only one or two displayed at the same moment, so there should only be one or two of this objects in memory.
Make a test so that when you reach the end of an active the next one loads. You could also use the same two actives all the time and make them move and change frame whenever they get out of screen.
You'd use even less memory if you used a fake scrolling and had the playfield at the size of your window.
Posting Permissions
Reply With Quote