Ouch! No Alpha = No Collision = Crap!
JodyMitoma
Member Posts: 307
I just made this awesome 3D terrain using 3DS Max, and I put it in my game, and, well, it slipped my mind that the collision enumeration doesn't take Alpha (transparency) into effect, but instead makes it a rectangle, so now my dude is walking on air at certain times (when the terrain slopes down, etc..)
What a DRAG. 
Comments
The only way I'd be able to get this to work is if I literally took "collision" off for my 3d terrain, and made my own transparent actors that follows the terrains slopes, and put collision on all of them (there would literally be hundreds of them!)
That's how we all do it, there is no pixel level collision unfortunatly
@JodyMitoma, believe me, the "other" way is no blessing in situations like you describe - you build your level, then decide to change some scaling on objects and you need to adjust dozens of collision polygons - you will long for the days where you just needed to move a few actors around.
Hmm, that was actually a LOT easier and faster than I would of thought...
Hey @jonmulcahy, does this hurt the processing power much, having so many transparent collidable actors?
@JodyMitoma, not as much as you would think. You can put 100 non movable collision actors on the scene and GS wont even break a sweat.
@Hopscotch, Thanks. Do you know why if I put a large background, and 3 large terrain images in my level, that one image always decides not to load? Too many pixels of imagery in one scene?... I'm talking 4 images that are 2020px wide each. But none are over the limit?!...
@JodyMitoma, does it do this in the viewer? Maybe a RAM problem on your machine. Try an adhoc build on the device, it should be able to handle it.
Yeah, a ton of problems in the viewer - all the time.
This time, my entire UI is not showing up, even though it is made up of 14 different actors! >.< Wtf.. haha
I've never once tried hooking it up to my Android, so I don't know how.
Oh, I'm not Pro, actually.. so I can't. >.<
@JodyMitoma , running on Mac? I have had projects which are that size and worked, not tried it in the new build though.
Oops. No, Windows. Simply posted here because there are more threads. (shhh!
)
Where are you placing this 4th image ?
@JodyMitoma , just tried it on Windows (a scene with 4 BIG image actors), and jup, brings it to its knees. :P
It is the parallax / scrolling background.
Do you know if this would bring an iPhone to its knees? lol... I doubt it, as those things have processors greater than my 3 year old laptop. -_-
@JodyMitoma , seems like it is unstable right after importing the images. After reloading I now have a scene, 4096x4096, 4 actors with 2048x2048 images, and camera movement is smooth floating around the scene.
Figured out the whole UI missing problem.
I moved the camera up 100 px because my terrain was going so low, it would go out of frame, and my Player would go out of screen, so I had to move everything up. But for some reason, even though I moved the UI up too, it decided not to display in screen, ever. So, I just moved everything back down for now.
BLAHHHHHH
The scene will take up 64MB for images alone, but yes it will be fine on the later devices.
So what you're saying is Preview is smooth, but GameSalad Creator isn't? Because when I'm actually working on my game, things are craaaaaaazy buggy and slow. But when I preview my game in the Previewer, they are very smooth sailing (except for at times, an image will decide not to display! (USUALLY the background image).
That poses a problem. I have 27 levels to do. 9 different background images, and, well, 27 different terrains.
I'm NOT down for having an 800mb side scrolling game.......
@Hopscotch, Okay, lets get serious here... I guess creating customized terrain for a side scroller that has levels that last anywhere between 2 and 4 minutes is NOT a good idea.............
6 to 12 images that are 2048 px in length, times 27 levels = 162 to 324 images that are 2048px would be about...... 8 to 16GB's... Uhhhhhhh?... wtf
@JodyMitoma , we know the windows version is not the most stable, throwing this much at it will not make it man up and deal with it any better
Rephrase this please, I am not following.
I said that according to my sizes (4 2048x2048pixel images) would take up 64MB of memory per scene while running. The file size may be much smaller.
Is there no way of chopping up your scenes and reusing repeatable images where possible to reduce the overall size?
This is the very heart of game design, from Mario to iOS, to make a limited resource pool look like an infinite word (or at least a long level), images need to get repeated and rotated and colours changed and so on, every game that operates in a limited space needs to play this memory game.
Thanks @Socks, I was getting to this, Possible does not equal Practical.
@Hopscotch. The way I was doing it, was creating each level in 3DS Max, and chopping them up.
But this would mean a good twelve 2048px images per level, and 27 levels in the game. It just wouldn't be feasible.
@JodyMitoma, how big are your files on disc for one scene when saved according to the new guidelines?
If you design and render out your levels in Max, then I assume the are pretty detailed and will take about 10MB per scene (on disc), making your game about 270 MB heavy. This is still reasonable.
However... look at your art again. As @Socks says, usually you construct your levels in such a way that you have a few large repeatable / tileable building blocks to make the main structure of the level. You then scatter variations (flipped, rotated, etc.) of a few detail images around the scene to make every corner look unique and handcrafted.
Holy SMOKES. This slipped my mind last night. Thank you, thank you, THANK you for taking the time to post this!
Man I love you guys, haha.. THANK YOU!!!! 4,000 Awesome's for you.
PS. They were 2.5MB's a piece, which would make each level 25 - 30MBs. But I'll be doing chunks like you just so kindly shared with me.