nesdev.org

It's a problem with powers of two and how arithmetic AND works as a fast module. As a rule of thumb, "a % b" can be calculated as "a & (b-1)" if b is a power of two. As 5 is not a power of two, you can't do the trick here.

Always stick to powers of two, otherwise you'll have to use modulus (a no-no as it is slow) or check for boundaries by hand when you increment or decrement the value to adjust.

Long story short: use 8 rooms and calculate the modulus using & 7, or use 16 and use & 15 and so forth. Only valid for powers of two.

Long story long, you'll see this with an example.

7 % 4 = 3.

7 & 3 = 3 -> 00000111 & 00000011 = 00000011.

.

7 % 5 = 2.

7 & 4 = 4!! -> 00000111 & 00000100 = 00000100. Not right.

I myself tend to use 16 rooms for horizontal scrolling stripes in my maps as you get a fairly large area to play, 256 tiles wide. Maths are simple as you are dealing with powers of two, plus you can use fixed point maths with 4 bits of precision. 16 rooms are 4096 pixels wide. 4 bits of fixed point precission gives you a minimum increment of 1/16 of a pixel, and you can store X coodinates using a simple unsigned int (max 65536 values = 4096 x 16).

I'm away from my computer, but I think I understand you...

So my code does...
++Room;
Room &= 3; to keep it 0-3

Changing to...
Room &= 4;

Won't work. It will merely keep you in room #0.

You need to...
If (Room > 4) Room = 0;

Yes, dougeff

Parameters
Room &= 4;
RoomPlus &= 4;
RoomB &= 4;

etc... not working properly.

Using
if (Room > 4) Room = 0;
if (RoomPlus > 4) RoomPlus = 0;
if (RoomB > 4) RoomB = 0;

etc... and it works as I want.

Once again, thank you so much!

Reviewing the lessons I have seen that there is something not clear in Lesson 1...

How do you know the program where the tiles of letters CHR are? Magic?

Is it TEXT [] a predetermined array
________________________________________________________________________
Spanish:
Repasando las lecciones he visto que en la lección 1 hay algo que no tengo claro...

¿Como sabe el programa donde están los tiles de las letras del CHR? ¿Magia?

¿Es acaso TEXT[] un array predeterminado?

If a program uses CHR ROM, and the mapper is NROM or something else incapable of bank switching CHR ROM, then the tiles are already available to the PPU from the moment the power is switched on.

CHR RAM or bank switching would complicate things, as the program would have to do some setup in order to make the tiles available. In the case of bank switching, it would have to write bank numbers to the mapper's ports. In the case of CHR RAM, it would have to copy the tiles from PRG ROM to CHR RAM through the PPU.

tepples wrote:If a program uses CHR ROM, and the mapper is NROM or something else incapable of bank switching NROM, then the tiles are already available to the PPU from the moment the power is switched on.

CHR RAM or bank switching would complicate things, as the program would have to do some setup in order to make the tiles available. In the case of bank switching, it would have to write bank numbers to the mapper's ports. In the case of CHR RAM, it would have to copy the tiles from PRG ROM to CHR RAM through the PPU.

Ok, thanks for the explanation.

I'm still progressing slowly. Now I'm involved with collisions. For now all right.

I made my character move a box around the screen. I've also got to shoot.

Now my question. How do I get sprite disappear from the screen? For example, when shooting touch the box, these two items disappear. How do I delete them?
________________________________________________________________________________
Spanish:
Sigo progresando poco a poco. Ahora ando liado con las colisiones. Por ahora todo correcto.

He conseguido que mi personaje mueva una caja por la pantalla. También he conseguido que dispare.

Ahora mi duda ¿Como consigo que desaparezcan sprites de la pantalla? Por ejemplo, cuando el disparo toque la caja, que estos dos objetos desaparezcan.

Diskover wrote:How do I get sprite disappear from the screen? For example, when shooting touch the box, these two items disappear. How do I delete them?

Normally, game objects are placed into RAM slots. Game engines are made to support a certain number of active objects, and every frame these objects are updated and drawn. Deleting an object is just a matter of freeing up its slot, so the object will cease to exist and will not be updated or drawn anymore. Games with a constant number of objects, such as pong (which always has 2 paddles and 1 ball), can get away with having hardcoded objects, but any game that involve objects being created and destroyed dynamically needs to have some sort of object management.

When a bullet hits an enemy, the common thing to do is destroy both objects (freeing up their slots) and create a new explosion object.

Also, giving a sprite a Y coordinate between $f0-ff will put it off the screen.

But, I also agree with Tokumaru. You'll need a system that (every frame) looks at what sprite objects are active, and how it should be drawn on screen, and reinserts those values into the Sprite Buffer...and clear the unused sprites by inserting a Y value above $f0. Every frame.

Ideally you would also shuffle the sprites 'priority' (position within the buffer) on every pass, (because of the 8 sprite per scanline limit) so that they* flicker rather than disappear.

*in this context I mean the 9th sprite on screen on a scanline will disappear. Unrelated to your question about making sprites disappear.

Now my question. How do I get sprite disappear from the screen? For example, when shooting touch the box, these two items disappear. How do I delete them?

Knowing how to program an object system is fundamental to any platform, including the nes, as was graciously explained to me a while back.

tokumaru wrote: Normally, game objects are placed into RAM slots. Game engines are made to support a certain number of active objects, and every frame these objects are updated and drawn. Deleting an object is just a matter of freeing up its slot, so the object will cease to exist and will not be updated or drawn anymore. Games with a constant number of objects, such as pong (which always has 2 paddles and 1 ball), can get away with having hardcoded objects, but any game that involve objects being created and destroyed dynamically needs to have some sort of object management.

When a bullet hits an enemy, the common thing to do is destroy both objects (freeing up their slots) and create a new explosion object.

dougeff wrote:Also, giving a sprite a Y coordinate between $f0-ff will put it off the screen.

But, I also agree with Tokumaru. You'll need a system that (every frame) looks at what sprite objects are active, and how it should be drawn on screen, and reinserts those values into the Sprite Buffer...and clear the unused sprites by inserting a Y value above $f0. Every frame.

Ideally you would also shuffle the sprites 'priority' (position within the buffer) on every pass, (because of the 8 sprite per scanline limit) so that they* flicker rather than disappear.

*in this context I mean the 9th sprite on screen on a scanline will disappear. Unrelated to your question about making sprites disappear.

Sogona wrote:Knowing how to program an object system is fundamental to any platform, including the nes, as was graciously explained to me a while back.

Ok, guys. I note your advice. Not if I'm doing well but at least they are leaving things.

I pass a demo of what I'm getting to see what you think.

My character can move a box and also shoot to destroy this or the enemy.

DEMO alpha 0.06: https://dl.dropboxusercontent.com/u/319 ... 200.06.nes


Spanish:
Ok, chicos. Tengo en cuenta vuestros consejos. No se si lo estoy haciendo bien pero al menos van saliendo cosas.

Os paso una demo de lo que voy consiguiendo a ver que os parece.

Mi personaje puede mover una caja y además disparar para destruir esta o el enemigo.

Looks good, keep working at it...

I see you're using the my controller read code that is buggy. I've since then updated all the links on my blog...see this discussion for the newer code...

viewtopic.php?f=2&t=13796

dougeff wrote:Looks good, keep working at it...

I see you're using the my controller read code that is buggy. I've since then updated all the links on my blog...see this discussion for the newer code...

viewtopic.php?f=2&t=13796

Thanks!!!

I've updated the code controls

How did you know I was using the old?

Spanish:
Ya he actualizado el código de los controles

¿Como sabias que estaba usando el antiguo?

I do a lot of Rom Hacking. Plus, I was worried that people are using the buggy code.

Anyway, I set a breakpoint for reads from $4016.

I have a few entertaining days with this issue and there have been several advances, such as the doors to move from a screen to another.

Right now I am studying the issue of creating a menu and at least've already got that pressing START freeze the action, change the screen and get back as it was before.

This morning I created the item selection arrow. It has emerged a rare problem. By putting the arrow, two rare tiles appear at the top of the screen. I do not understand that appear.

Similar cases passed when I did not give a memory size to declare the array of "SPRITES_X[]", in this case FLECHA_SPRITES[0x04];. Nor if this could be the error.

Can you think of anything?
ROM: https://dl.dropboxusercontent.com/u/319 ... 200.08.nes

Spanish:
Llevo unos días entretenido con este tema y ha habido varios avances, como por ejemplo las puertas para pasar de unas pantallas a otras.

Ahora mismo estoy estudiando el tema de crear un menu y al menos ya he conseguido que al pulsar START congelar la accion, cambiemos la pantalla y poder volver como estaba antes.

Esta mañana he creado la flecha de seleccion de item. Me ha surgido un problema raro. Al poner la flecha, aparecen dos tiles raros en la parte superior de la pantalla. No entiendo por que aparecen. Casos parecidos me pasaban cuando no daba una tamaño de memoria al declarar el array de "SPRITES_X[]" , en este caso FLECHA_SPRITES[0x04];. Tampoco se si este podría ser el error.

¿Se os ocurre algo?

Without the source code, I won't be able to figure it out. Clearly, 2 incorrect spites are appearing.

Have the linker make a label file. Find the address of the label that handles sprites. Set a breakpoint in the FCEUX for execution at that address (at the same time it happens). Step through the code, and see what numbers are being loaded to the Sprite area of RAM.

Or, review that RAM in the hex editor tool, and see the exact address of the strange sprite. Set a breakpoint for writes to that RAM area, and try to figure out where those numbers are coming from.

Learning to debug is an important lesson. I spend at least 25% of my time fixing bugs.