Author Topic: Portal Prelude (Read 227663 times)

Runer112 · « **Reply #465 on:** August 20, 2010, 09:23:07 pm »

I have an idea: as you design levels, post the uncompressed tilemap data and pose a challenge to see who can compress them the best.

I'd love to try that.

And while I'm here, I was wondering: isn't 4 tiles (as you showed in your demonstration) a little too few? Don't you need things like doors and switches and emitters?

DJ Omnimaga · « **Reply #466 on:** August 20, 2010, 11:32:37 pm »

Interesting stuff. How long would it take to decompress in Axe, though?

shmibs · « **Reply #467 on:** August 21, 2010, 12:17:06 am »

from the way it looks, about the same amount of time as it would take to draw his normal map twice, which is very little(it's slow in the screenie because he's updating the screen after every single tile is drawn instead of once after they all are). i can see how, if not done properly or if the map is really complicated, this could actually lead to an increase in size, so if you're still doing custom levels for this(i dont remember if you said you were ore werent and am too lazy to check, so sorry if im being redundant) make them one level rle and the included levels two. oh, and then just skip over the second drawing for custom levels. i also like runer's idea and would definitely be willing to give a level a go. however, this might end up being a bit of a spoiler...

Builderboy · « **Reply #468 on:** August 21, 2010, 01:04:09 am »

Yeah Shmibs your right, it would take 2 times as slow to decompress, but its the displaying that takes a lot of time. And as for tiles, the version only supports 1 less tile bringing it to a total of 15 tiles. BUT this does not include button tiles, door tiles, or either of plasma tiles, as those are added to the tilemap after decompression. This is for 2 reasons:

1) Makes it so that less tiles need to be in the tilemap data
2) Tiles that are only 1 in the entire map make the compression about 3 bytes less, so its no good.

And so i must point out that there is another possible optimization. Right now, 1 byte is used to represent a tile type and tile length, with 4 bits for each. Buut i might be able to have 3 bits for type and 5 bits for length if i find out that i have few enough tiles, and that could also lower compression. We shall see, this is all very experimental, and im not even sure im going to make any changes at all

Runer112 · « **Reply #469 on:** August 21, 2010, 02:35:15 am »

Well if you do start releasing uncompressed level data and challenging us to compress it as best as we can, I'll be waiting to take on (and win) that challenge. ;-)

bwang · « **Reply #470 on:** August 21, 2010, 04:43:31 am »

What is the current level format?

ztrumpet · « **Reply #471 on:** August 22, 2010, 10:09:08 pm »

You guys sound like you'd like compression-competition.

I wonder how small it could go, though.

Builderboy · « **Reply #472 on:** August 23, 2010, 01:03:48 am »

Actually ive decided to leave compression where it is for now and finish working on the game

DJ Omnimaga · « **Reply #473 on:** August 23, 2010, 02:55:50 am »

I lost the game

Anyway I guess it isn't really that necessary if the game is already not too small. If levels were like 400 bytes each, then it would probably require compression, to not require too much archive, but otherwise it might be fine I think.

Builderboy · « **Reply #474 on:** August 24, 2010, 02:37:29 pm »

So progress on everything is going slowly recently. But i managed to track down and eradicate a particularly tricky bug, took me all of last night to figure out what was going wrong

I also discovered another bug involving the boxes and terminal velocity, and im considering running the box physics at the same rate to fix this problem. I will have to run some tests to see if it will make it run too slowly though...

DJ Omnimaga · « **Reply #475 on:** August 24, 2010, 05:24:10 pm »

I see, what was the bug you managed to fix?

Good luck on keeping the game fast enough and fixing the other bug. What exactly does the bug causes?

Builderboy · « **Reply #476 on:** August 24, 2010, 11:22:41 pm »

The bug that i managed to fix was a bug where shooting a Portal into the top left hand corner would not work under very very specific conditions. Finally i figured out what the issue was, added 2 lines of code and fixed it.

The new bug is where you grab a box, get in an infinite loop to bring your speed up, then let go of the box. What happens is the box is released at a speed that is faster than it is allowed to go, so the code for the box doesn't work and the speed for the box increases infinitely.

DJ Omnimaga · « **Reply #477 on:** August 24, 2010, 11:46:14 pm »

Aah ok. I remember in the first demo, on startup, a portal always appeared automatically in that corner. Is it related?

And lol at the other bug it seems weird. You should have made a screenshot

shmibs · « **Reply #478 on:** August 25, 2010, 12:13:01 am »

cant you just check if the box is moving at a faster rate than is allowed and adjust its speed accordingly? would that slow things down too much, or what

Builderboy · « **Reply #479 on:** August 25, 2010, 01:31:45 am »

Yeah, that is one of the options. The other is to run the box physics at twice the speed so there is no difference, but im still testing to see if there is a significant speed loss.

Author Topic: Portal Prelude (Read 227663 times)

Runer112

Re: Portal X

DJ Omnimaga

Re: Portal X

shmibs

Re: Portal X

Builderboy

Re: Portal X

Runer112

Re: Portal X

bwang

Re: Portal X

ztrumpet

Re: Portal X

Builderboy

Re: Portal X

DJ Omnimaga

Re: Portal X

Builderboy

Re: Portal X

DJ Omnimaga

Re: Portal X

Builderboy

Re: Portal X

DJ Omnimaga

Re: Portal X

shmibs

Re: Portal X

Builderboy

Re: Portal X