Ghosty Ghost

[CunningFellow]

Nice work.

I am however very very terrible at it. Best I could manage was 4 and that was a fluke.

[D3thAdd3r]

It's funny how addictive this is while at the same time maddening. I don't think there could be a better game for the first Uzenet high scores because if I ever managed to score 10 I would want the whole world to know about it!

[uze6666]

I am however very very terrible at it.

...if I ever managed to score 10 I would want the whole world to know about it!

Same here!

[D3thAdd3r]

I'm currently using eeprom block 117, so if that's a conflict with someone else' upcoming game let me know.

I think this is one of the better and addictive games and it's basically finished. I put your block ID in the EEPROM block ID Reservation List, which has traditionally been whoever makes the claim first, and threw together a basic page for your game on the wiki here. You can request a wiki account so you can change and add things as needed in the future.

BTW that screenshot on the wiki, which you can change of course, no, I cannot get even close to 50 points yet(off topic: my eeprom is full of that score with only a minute of work, relating to good people/moderators being easier security for implementing high scores in the Uzenet discussions...obviously I would never send that to UzeNet).

[uze6666]

When you are ready to officially release I'll publish a news event.

[kivan117]

I think this is one of the better and addictive games

Thanks! Glad you guys seem to enjoy it I thought it'd be a good fit to encourage Uzenet adoption. I have some secrets for best playing techniques, carefully crafted in my hours spent play testing it. I still struggle to reach 20 on a good run.

no, I cannot get even close to 50 points yet(off topic: my eeprom is full of that score with only a minute of work, relating to good people/moderators being easier security for implementing high scores in the Uzenet discussions...obviously I would never send that to UzeNet).

Of course, attempting to outsmart the hackers is pretty futile as history has always proven. Even if uzenet was hardware only and I didn't submit scores from eeprom and only sent them direct from the active game session's ram... The protocol will be completely open so you could literally write a program to spoof scores for any game with minimal effort. Not terribly worried about that to be honest.

When you are ready to officially release I'll publish a news event.

Thanks! I still want to polish up a couple things (attempt parallax as D3thAdd3r suggested perhaps, make the menus a bit nicer, odds and ends) and super triple check for bugs first. Obviously I can't finish up my online high score stuff quite yet but that can be a post release update with no problems.

On the subject of parallax, the city is composed of a layer of clouds, upper cityscape, and lower cityscape. It's five tiles wide for a total of 15 tiles... I'm afraid multiplying that by a full 8 would be too many tiles, what with some reserved for ram tiles and all. I could separate out the menu tiles into their own set but I think I'll still have too many. Any ideas?

[D3thAdd3r]

I have only noticed 1 thing that might be considered a bug, perhaps it's intentional. When you crash into a wall, and I assumed I pushed the button that exact tick, you will hear the "flap" noise even though you just lost. I would guess that collision is processed before movement logic, and perhaps you trigger your sound effect in the input routine? Just once it mad me mad because my best looking run ended and I simultaneously heard the flap. I was like "I flapped!, I FLAPPED!!", super minute detail and not worth major restructuring of logic flow for it.

Parallax, the ghost looks 24x24 pixels which would need only 16+(3*2)=22 ram tiles to display the ghost and a score up to 999(requiring 3*2 ram tiles) and have up to 256-22=234 indices left for tiles. Should be easy to use a separate tileset for the title and for the gameplay since the title must take >100 tiles and the game must have at least 80. If you split it up it should not even be close to out of indices. Flash space you should be good on but (7 extra offsets*15 tiles*64 bytes) = 105 extra tiles = 6720 extra bytes which you probably have available. Might be a small but complex piece of code that handles updating vram, probably why no one has ever done it yet.

Edit-Alec wasn't there a parallax cityscape in one of your videos? Was that an actual Uzebox program generating that?

[uze6666]

On the subject of parallax, the city is composed of a layer of clouds, upper cityscape, and lower cityscape. It's five tiles wide for a total of 15 tiles... I'm afraid multiplying that by a full 8 would be too many tiles, what with some reserved for ram tiles and all. I could separate out the menu tiles into their own set but I think I'll still have too many. Any ideas?

Using ramtiles is a possible way if you have enough free. You'd use a similar technique a I used for LodeRunner's title screen. However you need a way to tell the kernel to reserve some tile for the user. I recall Lee asked for that, but can't recall If I actually implemented it. That would not be a big thing to do though.

Edit-Alec wasn't there a parallax cityscape in one of your videos? Was that an actual Uzebox program generating that?

Nope, that whole video was 100% made in Adobe premiere.

[kivan117]

I'm afraid some of my initial assumptions about how mode 3 operates may have been wrong so before I start work on the parallax aspect I'd like to clear them up.

I know I have 256 total tiles. I know ram tiles used counts against that. Obviously the tile set you have assigned for use at the moment also counts against it as well.

What about sprites though? Drawing them uses ram times but does the number of unique tiles in the sprite set count against your 256? What about for sprite sets not set as the one for use?

If you set a number of ram tiles in your make file do they always count against total tiles or just reserve ram?

What about font tiles? Do they count against your 256 as well?

Finally, if they're not assigned as the active tile set for use, other background tile sets don't count against the 256 do they?

When I get around to working on this Friday I just want to have any misconceptions out of the way so I can finish it as fast as possible and maybe even add some more graphical variety if there's room.

[D3thAdd3r]

I'm afraid some of my initial assumptions about how mode 3 operates may have been wrong...

That is a universal thing but you are learning quickly to already have a scrolling game sitting in front of us.

Obviously the tile set you have assigned for use at the moment also counts against it as well.

One thing that makes it seem confusing is the notion of tile set as something more than a pointer(it is nothing more than that). Also thinking fontset is anything besides an index where the first fonttile is in your tileset so that print() knows which tile is 'A' for example. Vram is just an array of 8 bit values and based on that value the scanline renderer knows to draw from flash or precalculated ram. Any number there that is < RAM_TILES_COUNT is always interpreted as a ram tile when the kernel draws the screen. Any indice >= RAM_TILES_COUNT is a flash tile, so it will start at the address you specify for the tileset then offset (tile*64bytes) to get the first pixel of the tile there. So, if you have 22 RAM_TILES(0...21), and you set "vram[10] = 22;" you will see at the very top, in the 11th horizontal spot, of the screen the first tile in your tileset(tile 0). So "vram[11]=RAM_TILES_COUNT+4;" would instead put tile 4 in the 12th spot. Stuff like print, DrawMap, sprites, etc are niceties over the top of this lower level system so you don't have to reinvent the wheel for common things. Check out here. Most of that is probably basic to you, but even this thread might be of interest.

As far as the tileset pointer, that is used during rendering, but you always have 256-RAM_TILES_COUNT unique tile indices available even if that is more than you actually have tiles in the current tile set(which is really just an address to the first byte of that data). One for this is to put a font set between the title and the gameplay tiles. Now the title can access the font and so can the gameplay, even though the title might be too far away to access game play tiles and vice versa. You would need to adjust your tileset and font pointers for the kernel functions to work correctly and of course your drawing functions would need to be aware of the offsets, it can get complicated but depending on the game it's worth it. That's a whole other subject.

What about sprites though? Drawing them uses ram times but does the number of unique tiles in the sprite set count against your 256? What about for sprite sets not set as the one for use?

No, because sprites are a structure that is not used during actual frame rendering. Sprites are only used to determine how to draw ram tiles, when it comes time to draw to the television all pixels have to be figured out beforehand..ram tiles are like mini frame buffers. Sprites tile set is a different pointer and doesn't affect your tiles pointer because it is only used by BlitSprite() which doesn't directly change vram(ProcessSprites does, by setting vram to the ram tile that was blit for the sprite there). Inside of vram(for mode 3 at least), there is still only every 2 things: ram tiles or flash tiles. Basically if some piece of a sprite overlaps a 8 pixel tile boundary you have to put a ram tile there. Copy all the pixels of the tile underneat the sprite(so it looks consistent), then using the sprites coordinate and tile index draw the correct pixels over the top of that. Because of that, each 8x8 sprite could take up to 4 ram tiles. Check out here and here for more exhaustive info, but that's probably all you need to know, then some experimentation for those types of things you can't really understand until you figure them out yourself.

Edit-it's hard to explain and sometimes more words isn't better. Think of the tileset pointer as the start of a window that is 256-RAM_TILES_COUNT long. If there is data after your tileset that is in range, then that will be interpreted as flash tile data as well. Font is flash tiles exactly like your other ones.