Tyger

Discuss how totally awesome Bang! is here.

Moderator: Terryn

User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post by Dr. Dos »

Fun fact:

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

TIM :argh:

User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post 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.

User avatar
zamros
my power level is enormous
Posts: 541
Joined: Thu Mar 20, 2003 9:34 pm

Post by zamros »

are you high

User avatar
Kjorteo
^o.O^
Posts: 432
Joined: Sat Feb 28, 2004 10:59 am
Location: Kjorteoville or something
Contact:

Post 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.
"You're alive," said the maker, and smiled at the aardvark.

<Kjorteo> "yiff"
<gbelo> Wanna yiff.
<Kjorteo> yes
<gbelo> No no no.

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

palette swapping

and what crazy asshole gives out F's for "hello world" programs?
*POW* *CLANK* *PING*

Microwave
hi
Posts: 114
Joined: Fri Aug 03, 2007 10:34 pm

Post 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.

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.

User avatar
Dr. Dos
OH YES! USE VINE WHIP! &lt;3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post 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.

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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).

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
Dr. Dos
OH YES! USE VINE WHIP! &lt;3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post 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

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

so long as you're taking my suggestions, you should add usb gamepad support
*POW* *CLANK* *PING*

User avatar
Dr. Dos
OH YES! USE VINE WHIP! &lt;3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post 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.

User avatar
Dr. Dos
OH YES! USE VINE WHIP! &lt;3
Posts: 1765
Joined: Tue Sep 11, 2001 9:11 am
Location: Washington

Post 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!

Post Reply