[CryinOnion]

Yo, people! Long time no see

First of all, I want to apologize to those who were patiently waiting for this hack. The project was progressing regularly, until for personal reasons I didn't feel mentally able to continue...until now.

To get back on track with the project, I started with something simple: make some improvements to the bonus screen. Now I think it looks in line with what one expects from a game starring Nintendo's mascot, although I still think it has room for improvement (with a little help from you).

A few months ago I opened a topic in this forum about how to reassign sprite palettes.
https://www.romhacking.net/forum/index.php?topic=31699.0

Now I want to do the same with some background elements, like the card of the screenshoot.


As far as I could check, A9 is the hex value of the sprites and their corresponding palettes go from 00 to 03, so if a sprite has 00 assigned for example, I just have to look for an A9 00 value, change it, and see if it has the result I'm looking for. But does anyone know if the background elements work the same way? If so, what value is assigned to it? And their corresponding palettes? They also go from 00 to 03 or use something similar, like from A to D?

Any help would be welcome.

[Cyneprepou4uk]

https://wiki.nesdev.com/w/index.php/PPU_attribute_tables

Set a write breakpoint to the PPU attribute address to find out where this value is coming from.


A9 is an opcode for LDA instruction, it's not a value of the sprites or whatever.

[sics]

NES games handle their graphics in many different ways, but for practical purposes it will be best to focus only on the fundamentals to achieve your goal

There are mainly two types of screens:
First there is the one that basically consists of a single block of data, which may or may not be compressed, but you will be happy to know that this is not the case:

Code: [Select]

Data   Graphics
22010 | 24010
22E50 | 3F010
23530 | 3D010
23B10 | 3D010


Spoiler:

Note 1: In Djinn Tile Mapper you must add the 0x prefix to the pointers to use them in the "Go To..." window, Relevant link.


Note 2: Actually there is also the possibility that there is a screen made up of several of these blocks or that they have additional programming, but this is not the case...

Note 3: You can find the X value of the hammer from the title screen at 0xC4EC, moving it will allow you to align the text "Begin new game".

In the following tutorial RoboCop Tilescreen, you will find relevant information to be able to correctly understand the attributes of palettes of this type of screen, although currently it is best to use NES Screen Tool 2.51 to distribute the palettes and then export the data as follows:

In the "Nametable" tab you must activate only "+ include attributes" and save as binary with "Save as binary".


You open the .BIN file with your favorite Hexadecimal editor and copy its data and insert it into the game with the emulator.

Let's talk about the second type, this can vary in complexity, but basically it is a structure formed by "legos", here you are also lucky, since they are ordered in a simple way:


Going deeper, there are many blocks that are used to create the structures that make up each background image, the most common thing to see is that they are used to build levels.

Here would go a long explanation. but better let's see its basic structure, which in this case is:

Code: [Select]

30bdd | 30c0d Palettes assigned to each block.
30C34 | 30DB4 Graphics.
30fb4 | 30fe3 Distribution of blocks on the game screen.


Spoiler:

Surely there is a block intended to define the type of physics that each object will use, but that is not important for the purposes of this tutorial.

What you should know is that these data groups function as lists, in which each object inherits its attributes from the element in the same position as the following list.

In other words, the 1st palette is from the 1st graphic, the 2nd palette is from the 2nd graphic and so on.

Spoiler:

In case you couldn't read the tutorial I recommended, remember that each palette attribute code stores the information of 4 different palettes, arranged in the following way:



Using clear, the four available palettes:

^{Note: I give these explanations omitting all the data that is behind the operation of the concepts that I explain, so it is recommended that you inquire about this information, otherwise you will be limited when trying to do new things...}

[CryinOnion]

Bro, I'm going to need a lot of fiber to digest this information!

For now, 90% of what you kindly try to explain is beyond my comprehension. I admit that I have avoided going into the programming more than necessary although that, as you rightly say, limits me. However, I appreciate your effort enough to try (after running it through the translator into my language) to better understand those concepts.

If until then you could come up with, let's call it a "way for dummies" to achieve a similar result I would appreciate it.

[sics]

It is ironic that even though we speak the same language we have to communicate in another

On the other hand, instead of just trying to understand my words, I recommend that you directly load the following addresses in the hexadecimal editor of the emulator.

Code: [Select]

30bdd Palettes assigned to each block.
30C34 Graphics.
30fb4 Distribution of blocks on the game screen.

That way you can edit random data, and see personally how this affects the game, you just have to make sure you enter the bonus after making your edit, so that the changes are reflected in the game, that way my words will make more sense