Tempest is possible

[CunningFellow]

How do you feel about fixed memory locations for the buffers?

Thats a bonus 3 clocks.

Also there is a decision reshuffle there that could save another 2or 3 clocks I think. Not in front of PC so will have to check that one later.

[CunningFellow]

Oh. And obviously you have a free odd/even scanline counter that could be used to alternate between TX and RX code.

(bit 0 of R10)

[D3thAdd3r]

How do you feel about fixed memory locations for the buffers?

This,I think it's a good idea but I'm not sure if it could work with an idea directly related to this. I am begging that the kernel gets an additional small feature which looks like this:

Code: Select all

//videoMode3.c->ProcessSprites()
	//...
	bt=vram[ramPtr];						

	if( (bt>=RAM_TILES_COUNT)  && (free_tile_index < [b]max_ram_tiles[/b] ){ //RAM_TILES_COUNT) ){

		//tile is mapped to flash. Copy it to next free RAM tile.
		//if no ram free ignore tile
		ram_tiles_restore[free_tile_index].addr=ramPtr;
	//...

I know it's necessary but these extra buffers are expensive and I am at this point insane about having enough ram tiles. I have held off from doing a couple things and simplified some graphic screens because I didn't want to make my games need a non-official kernel. The beauty of this would be you needn't define dedicated buffers for Rx/Tx or any other item that isn't used all the time. Instead you could have more ram tiles and set max_ram_tiles = RAM_TILES_COUNT and use them to display screens from SD, and then during parts of your game that actually need networking functioning you set max_ram_tiles = RAM_TILES_COUNT-(rambytes_you_need/64); and have your Rx/Tx buffers, or some big buffer you need for something else, at those higher value, temporarily unused ram tiles. It also makes protecting parts of ramtiles easier for some of the trickier ram tile effects.

[CunningFellow]

D3athAdd3r, Do you (and anyone else finding RAM limited) already do all the usual things like using unions/structures and bit packing to make the most of what is available?

[D3thAdd3r]

Yes definitely. I a little for Alter Ego, but for games that are really pushing it like Lolo I pack it to the max and also use parts of the kernel I dont need like sprites_tiles_banks[1..3] and multiplex stuff when feasible.

[uze6666]

How do you feel about fixed memory locations for the buffers?

Relocating variable/memory sections is a PITA so we should avoid it as much as possible. Mode 3 with scrolling uses it because the gains were so great. So we could always piggyback the buffer at the end of VRAM for mode 3 since it's already aligned at 0x100.

I am begging that the kernel gets an additional small feature which looks like this:
if( (bt>=RAM_TILES_COUNT) && (free_tile_index < max_ram_tiles ){ //RAM_TILES_COUNT) ){

Interestingly, I had done pretty much that I think when I did LoadRunner. It allowed the user to control the maximum ramtile index the kernel can allocate. It allowed me to blit stuff manually in ramtiles and guarantee that the kernel would leave them alone. The scrolling background, among other, was done with that. It was never included in the kernel since I thought I had lost this code just after completing the game. But I found it on my old WinXP machine. I remember that back then, I thought this user_ram_tile thing would be too confusing for most and would take time to document and explain...having to create pointers to ramtiles buffer sections on demand in not for the novices.

Code: Select all

if( (bt>=(RAM_TILES_COUNT-user_ram_tile_count))  && (free_tile_index < (RAM_TILES_COUNT-user_ram_tile_count)) ){

	//tile is mapped to flash. Copy it to next free RAM tile.
	//if no ram free ignore tile
	ram_tiles_restore[free_tile_index].addr=ramPtr;
	ram_tiles_restore[free_tile_index].tileIndex=bt;

	if(user_ram_tile_count == 0){
		CopyTileToRam(bt,free_tile_index);
	}else{
		if(bt<RAM_TILES_COUNT){
			CopyRamTile(bt,free_tile_index);
		}else{
			CopyTileToRam(bt,free_tile_index);
		}

Looking at it, it seems functional and could probably be merged in relatively easily. I can attempt to do it since I think there's value there. But I'd keep the default way of allocating the RX/TX buffer that's "easier" on everyone by using the compile switches UART_RX_BUFFER_SIZE & UART_TX_BUFFER_SIZE. If you don't want additional buffers, just don't define them and use new functions to point to their locations. What do you think?

ps: we should open another thread for this discussion.

[CunningFellow]

Changed the way collision actions work (now using function pointers) which makes adding extra enemies easier.

I just spent several days chasing down bugs with the function-pointer thing.

Its all sorted. I'll do a new release of T2K this weekend that looks a bit more polished.

Might even try squeeze in a title screen if Alec/Uze has some music for me.

[uze6666]

Might even try squeeze in a title screen if Alec/Uze has some music for me.

I didn't spent all that time on that song to see it go to waste! I'll convert it for your this week.

[D3thAdd3r]

This will be cool to see the new progress. Did you ever get the "jump out towards screen" thing working?

[CunningFellow]

Have not got jump going yet. Maybe this weekend when I am doing the title screen. They both need me to work in Qt.

I have been bug hunting a lot in the last few weeks and also polishing things.

Spent far too much time and effort in getting the flippers looking just right in their movement. Seems a bit silly spending a lot of time on that, but flippers are so big a part of the game.

I did go a bit mad with function pointers. They are used a LOT and it has made adding/extending things a lot easier. Can fully recommend people get that tool in their belt for any games/projects that handle a lot of different types of objects.