Hi all!
Lately I've been working on some alternative methods for tiles. Why? Because tiles are good for memory shortage, however when you have a LOT of tiles visible at once, that's a lot of individual drawing 'functions' for the computer, and it gives an FPS drop. Now, tiles are brilliant for some games, but for Conflict: Online, we have to find another method, because it's really making an FPS drop for many computers.So me, Scott, and Pim have been discussing various methods, and have been putting them into action in 'prototype' scripts. They've all got interesting results I'd like to show you guys. Method One: Whole Room in MemoryThis method is a pretty basic method, and follows an idea Tahnok100 had (thanks buddy) - pretty much, all objects are made invisible so only backgrounds and tiles are visible. Then, we create a surface the size of the room to capture the room, then save it to a background. The tiles are deleted, surface deleted, objects visibility restored, and then the new background is drawn at 0,0. Now, though this had perfect quality, we couldn't get the room to get very big before the game crashed from bogging up the memory. Quite obviously because you have a (say) 1500x1500 bitmap stored in the memory! So we then created a quality factor. The quality factor stretches the tiles and background into a certain resolution - 1 = no stretching/scaling, 0.5 = stretch it half the size, and so on. This way, we can halve the memory it takes up by using half the quality. The background is then drawn at 0,0, and stretched across the room. We had this result:However, we're still suffering with memory issues here. So, onto our next method.Method Two: Load/Unload SegmentsHere we used a similar method, however split the background into segments of (say) 640x480. We save each segment into a temporary folder, and so we only have to load between 2 and 4 segments at one time, depending where you are on the map. Then, when segments aren't needed at the moment, they're unloaded (or deleted) from the game's memory. This further caused problems. The memory was fine, but we returned to our root problem - the game ran a bit slow trying to figure out what segments needed to be loaded - plus loading the segment into the memory.Method Three: Only Necessary SegmentsThis is the method we're still working on - and I have a lot of faith that if we get the scripts working properly, it'll serve a brilliant result. Instead of rendering the whole background, we only render places that has tiles on them. We scan through the room for a tile, if we find it, save the xmin/ymin location there, then keep moving until we can't find tiles anymore (meaning that should end the segment), save the xmax/ymax values and then move on to look for more segments - then a surface browses through the segment values, and takes 'snapshots' of each segment, saves them to backgrounds, and then builds a data-list with all the positions to place the relevant segment.So yeah!S'lata guys-Rhys
Type "…" very slowly, and you've captured my reaction.
…
Hah! Now I've captured Takagi's reaction! I'ma stick it in a jar! =DI don't care, Bryan, if you can beat me when it comes to GML. I really couldn't care less - I know heaps of people that are much more intelligent than I am. What I care about is how I distribute my knowledge - I could be an uptight little shit like you and boast about how great I am and then bitch about everyone else, including whoever created the language you're using, which accomplishes nothing but hate. Or I could share my knowledge with the community and discuss techniques… makes everyone learn a bit more. Frankly, if you know a better method - great, but I don't care if you're not going to share it, because you're just a selfish bastard for one.
-RhysBecause you guys are jerks.
There is no need to do that.
You would have 2 surfaces, the terrain, and an alpha mask, then you'd multiply the terrain with the alpha mask surface.GearGOD, I have a hard time believing you can be so mean. How can you look in the mirror?