Page 1 of 1

Upgrading my background(s)

Posted: Thu Jan 19, 2012 3:29 pm
by log in
I have managed to make a background for my pong with the nerdy method.It looks great on screen but the code is a hudge mess.

So i was interrested in making it cleaner in my code .
Looked around on the forum and read topics like the background saga,understanding backgrounds etc.

I experimented with it and some things i like and some things i don't.

For ugrading my background i went with this :

-addr lo+high (variables)
-changing background 1,2,3,4 into the loop code.

-in other exsamples i also see .pal a incbin for the pallete but im not really bothered by that code so i want to leave it in.

-the attribute doesnt bother me also.



So in short.

1.i got rid of loading the background 4 times But i have to set LDX # and LDY # i have to look this up for getting a complete background.

2.How does the .map file work? I gues this is where the huge .db code is stored but how do you set this and wich program do you use?

3.Google or searcing BACKGROUND on the forum gives 1000+ results so if somebody knows good sites/links for detailed reads and information i would be very interrested.

4.Im jumping way ahead here but im curious what is the turning point for incbin? With a short game with titlescreen/credits/rules/game over and playing im guesing you would program with a couple of incbin screens,but how do many screens get stored not incbin i gues?

Posted: Thu Jan 19, 2012 4:17 pm
by Denine
2.How does the .map file work? I gues this is where the huge .db code is stored but how do you set this and wich program do you use?
.map files are binary files contaning pure data.Since it's called "map" I guess It's data to write to NT(Name Table).
I use "Name"by Tepples.
Important note:Loading Name Tables with map files is (somewhat) fine but I advise you to make use of Meta Tiles as soon as you can handle of backgrounds.
Full map steals 1024 bytes from PRG ROM!(960 for tiles data and 64 bytes for Attributes data)
4.Im jumping way ahead here but im curious what is the turning point for incbin? With a short game with titlescreen/credits/rules/game over and playing im guesing you would program with a couple of incbin screens,but how do many screens get stored not incbin i gues?
.incbin(for NESASM at least) means "include binary file".Binary file can be anything-Music, DPCM samples, Graphics, Name Tables, metatiles data, even code!(though it's not practical, I guess) How many screens fits into incbin? You mean binary file? Binary file can be as big as you want.(but please remember that NES can only "see" 32kb)

Posted: Fri Jan 20, 2012 9:26 am
by tepples
If your nametable has a bunch of flat areas, you could use run-length encoding to represent a horizontal line of identical tiles with fewer bytes. I've included a compressor and NES decompressor for the PackBits RLE format with both my old Allegro-based nametable editor (which Denine mentioned) and the newer Python-based one that's bundled with Concentration Room and Thwaite.

Posted: Fri Jan 20, 2012 2:46 pm
by log in
Oh boy this is going to be harder then it looked. :lol:

I thought this would be easy like draw it in YY or p8nes and push MS DOS BATCHFILE and it would create a .map or other file that i could use as a incbin.

ok 1 .I found NAME i put it in a map with alleg42.dll and im LOST i looked in neswiki but this section is empty..so how do i use this what should i put in my map etc.