Page 3 of 20

Posted: Wed Aug 19, 2009 10:59 pm
by Dr. Dos
Fun fact:

Clockwise conveyors are cycle 3
Counter-clockwise conveyors are cycle 2

TIM :argh:

Posted: Tue Aug 25, 2009 7:22 am
by Dr. Dos
So I really don't like the way graphics are currently handled.

The way it works right now is that every tile on every board has an image.

This image is its own image, there are many like it but it's its.

So for every board in the game there are 1500 tiles.

Wow that's dumb! Town of ZZT has 51,000 tiles this way.

But what if instead I made a giant array of 16 foreground colors * 16 background colors * 256 characters and shared the graphics. Then you'd have 65536 tiles. This is only worthwhile if a ZZT file has 44 or more boards in it. Somehow I doubt most games are this large.

But what if those images are created like in the first method, but stored in a giant array in the second?

Then you get an array with 65536 positions set to 0 and each image generated overwrites a 0. Python loves mixing types x = [0, 1, "HELLO", (5, 15), 3.2, [("X", "Y"), ("A", "B")]] is perfectly valid.

But it's not worth it if the game uses so many different tiles that the giant array ends up taking more space than individual images. So I decided to figure out how many unique tiles are used in a ZZT game.

Town uses 428 unique tiles
Aura uses 472
Frost uses 1918

For comparison using the 1500 tiles per board method:
Town uses 51,000
Aura uses 60,000
Frost uses 52,500

Although I have no idea what the actual memory requirements are for a 65,000+ slotted array. Granted an actual individual unique tile is only about 100 bytes as a png which would mean 6 megs for a filled array.

Posted: Tue Aug 25, 2009 8:05 am
by zamros
are you high

Posted: Tue Aug 25, 2009 8:09 am
by Kjorteo
What is the amount of space claimed by either approach?

Is this a situation where there is actual useful optimization to be had, or is it like one of those CS 101 classes in college where your five-line Hello World program that literally runs faster than it took you to click on it still gets an F because it's somehow NOT EFFICIENT in some principle-of-the-thing way or something?

I mean, actual ZZT is a program we run on computers with several hundreds of gigabytes of room on most of our hard drives, yet 300 KB for a .zzt file is still considered huge, but only because of the corruption and stuff that happens beyond that. I imagine Tyger won't have that limitation.

Posted: Tue Aug 25, 2009 5:06 pm
by Commodore
palette swapping

and what crazy asshole gives out F's for "hello world" programs?

Posted: Tue Aug 25, 2009 5:09 pm
by Microwave
zamros wrote:are you high
Damn, this made laugh. But yeah I was looking at the graphics files when I downloaded Tyger and thought that it was interesting, cause you could just edit the graphics files and it'd no longer have the ZZT feel. WAY BETTER THAN NINTENDO.

Posted: Tue Aug 25, 2009 5:51 pm
by Quantum P.
You could just toss the tile images you're not using. For example, you would only generate 1500 images for the current board; when you enter a new board, Tyger would toss those 1500 images and generate 1500 new ones. That would also speed up loading a new world, I imagine.

Alternatively, you could make your images one-time-use. For example, if you had to redraw a tile, you would generate an image, draw the image to the screen, and discard the image immediately. Don't know what kind of performance hit that would be, though.

Or, you could reexamine your graphics code and see if you really need images in the first place. You can store a character set in 256*14 bytes of memory (or 256*16 if you like the taller characters), and a 16-color palette takes up 16*3 bytes of memory. Then you'd write your own code for drawing, pixel-by-pixel, character c at (x, y) with foreground color f and background color b.

Posted: Tue Aug 25, 2009 10:20 pm
by Dr. Dos
Quantum P. wrote:You could just toss the tile images you're not using. For example, you would only generate 1500 images for the current board; when you enter a new board, Tyger would toss those 1500 images and generate 1500 new ones. That would also speed up loading a new world, I imagine.
But then if you go back to the previous board you're just going to make those 1500 images again.
Alternatively, you could make your images one-time-use. For example, if you had to redraw a tile, you would generate an image, draw the image to the screen, and discard the image immediately. Don't know what kind of performance hit that would be, though.
Discarding an image after it's drawn would be fine for things like walls, but anything that moves or can be pushed would need to remake the image.
Or, you could reexamine your graphics code and see if you really need images in the first place. You can store a character set in 256*14 bytes of memory (or 256*16 if you like the taller characters), and a 16-color palette takes up 16*3 bytes of memory. Then you'd write your own code for drawing, pixel-by-pixel, character c at (x, y) with foreground color f and background color b.
This also seems redundant since you'll still redraw the same image over and over.

Posted: Wed Aug 26, 2009 12:07 am
by Commodore
still I don't understand why you need to keep images that are off of the board in memory, is drawing them really that slow? Do you use monochrome sprites and change the colour on the fly?

maybe the images themselves are static but change their graphics when things move over them or when you switch to a new board.

I seems a like pain trying to replicate with sprites what dos does in textmode. I don't know, I have no clue what python is like.

Posted: Wed Aug 26, 2009 8:05 am
by Quantum P.
Dr. Dos wrote:But then if you go back to the previous board you're just going to make those 1500 images again.
Yes, that's the tradeoff. My point was that you could reduce the number of images you'd have to keep track of, at the cost of taking slightly more time to draw each board.
Dr. Dos wrote:This also seems redundant since you'll still redraw the same image over and over.
Yes, but keep in mind that if you make an image of a tile, you have to blit that image to the screen over and over. That's copying pixel data over and over.

I guess what I'm saying is if you can draw a tile from scratch about as fast as you can blit a copy of it, you don't need a copy.
Commodore wrote:I seems a like pain trying to replicate with sprites what dos does in textmode.
Megazeux has a software renderer and I believe not one, but two different hardware (OpenGL) renderers. And a config file, so you can set stuff like the preferred resolution, how you like your pixels scaled, etc.

In DOS, you did some minor fiddling with the screen mode, and then you could just start poking to memory in segment 0xB800 (thanks CyQ).

Posted: Wed Aug 26, 2009 8:43 am
by Commodore
I think writing your own drawing routine would probably give you the most flexibility. you wouldn't have to have separate sprites for objects moving over the background and you could maybe do flashing or the glowing message text more easily. maybe the dialogue box opening too.

Posted: Sun Sep 06, 2009 12:37 am
by Dr. Dos
Commodore wrote:still I don't understand why you need to keep images that are off of the board in memory, is drawing them really that slow? Do you use monochrome sprites and change the colour on the fly?
I am unfit for programming and after my overly complex array wasn't working out I just went with this.

So now Town uses about 55MB of memory as opposed to like 144

Posted: Sun Sep 06, 2009 1:46 am
by Commodore
so long as you're taking my suggestions, you should add usb gamepad support

Posted: Sun Sep 06, 2009 7:58 am
by Dr. Dos
Commodore wrote:so long as you're taking my suggestions, you should add usb gamepad support
Yeah I can probably add that.

Posted: Sat Oct 10, 2009 4:59 am
by Dr. Dos
I've been working on this still! I swear!

I'm just really lazy.

Look at all these awesome things now implemented:

Tyger Specific
+ Screenshot function now continually increments as opposed to reseting to 0 each time a game is ran.

Graphics
+ Objects now render with the correct character
+ If a solid/normal/breakable/water/fake wall has stats, it will use the value of parameter one for its character. This means custom-walls. Invisibles will also reveal themselves with custom characters if given stats.

ZZT Support
+ Ammo, Torches, and Gems can now be obtained with the HUD updating properly.
+ Player clones now cause you to "stick" to them teleporting the real player.
+ Bullets function mostly properly excluding ricochets. Creatures and breakable walls can be shot. The player can be hurt, but cannot die. He's kind of like Jesus.
+ The player can now shoot.
+ Fake walls now work properly.
+ Invisible walls implemented.
+ Keys and Doors implemented. Black keys do not give any gems, nor are they displayed on the HUD, however they do act normally essentially giving you 8 possible keys.
+ Games now start on the title screen and take you to the correct board when P is pressed.
+ "Number of Shots" board property properly programmed.

Known Issues with what is Implemented
+ Using a custom charset/palette does not yet work.
+ Putting an item beneath an item via Kev-edit causes the player to step twice when he grabs it.
+ Residue when switching boards

I will release a new binary as soon as I get as much of board switching implemented as possible. This would be a lot easier if not for ZZT doing god knows what with things on the border of a screen.

Make a board, put board edges along the bottom, make it so the board above is the same board

Then have another board have the first's above it so when you walk north you will hit an edge, move to the next board, immediately hit an edge you placed yourself, and move to the same board.

Also fun instead of a bunch of board edges place transporters instead you'll end up not going to the next board, but if you do from some other way you'll see a board edge is placed where the player would have been transported.

Fuck Tim!