nesdev.org

adam_smasher wrote:AFAICT, lidnariq's nomenclature is non-standard.

While they're called the DBR and PBR, they're set using the PusHBPulLB and PusHKPulLK instructions respectively ...

Of course, "B" also means "the hidden half of the 16-bit A register when A is 8 bits wide" so, I think I'll just blame them for being bad at naming things.

(much like it both having the 16-bit C register and the C bit)

Well, I haven't done anything for a long time now toward this because I've been busy and I don't feel like reading an entire manual for one piece of information, so I made this:
It didn't turn out quite as well as I thought it would, but at the same time, I have no clue how to improve it. I don't know if everything is really proportionally correct because I just looked at pictures, but I'd say it's "good enough". Better than the other shit I've seen people have drawn anyway...

I don't see any possible way to implement different clothing if I ever get there because of color and tile issues. I hate perks anyway.

I'm going to miss the hat shop though, If ya know what I mean...

Well, actually, I feel like being productive now and I downloaded the pdf for the 65816 manual, but I realized that I don't really know what I'm looking for... However, I narrowed down my search to two chapters:
When it says "long" addressing, is it talking about 24 bit?

Anyway, about artwork, I realized something, and that's that I'm not really sure how to go about something. I could either go about having a palette with the two main colors and then whatever extra for items and whatnot and then have a palette for the rest of the characters (the characters would use overlayed sprites) or I could essentially have a copy of the palette for each character but then I wouldn't have the extra half palette and I figure that if I want the character to visibly take "damage" in that the other team's color is on them, I'd need to use overlaying sprites anyway. Thinking about how many colors each character should take up (4 for hair, 4 for white shirt and black pants, 3 for skin, 3 for green colors (tank on back) 2 for red colors (also tank on back) 2 for shoes, 2 for laces) there's no way I could include the hair as part of the sprite. I would have to make 2 different copies of each character for each color, (4 really for male and female) but oh well. By the way, I'm basing how I want the character to look off this picture: (This is the smallest picture I could find)



One thing I've found out about this game is that the lighting is really weird in that things don't go from one color straight down in value, but they kind of actually change color like how orange starts to have a purple tint (It's not just the color of the tentacles, look at the shadow that's being projected on them from the gun) Speaking of the tentacles, the spots on the bottom on some pictures seem to be darker than the area they're on, and then lighter in other pictures. Even this official image isn't sure:



Just rambling on, I don't see how I'll be able to get all the gun colors in 8 palettes, (these will undoubtedly be different sprites) so I think I'll reserve 3-4 palettes and split them up to where for each gun onscreen. (there will be several copies of the guns) I'll fit the characters and the display and the special and sub weapon and tower/rainmaker palettes in to whatever is left. If this gets finished, there's going to be a lot of seemingly redundant data... 4 copies for hair (the body can probably stay the same for the girl and the boy, even if the girl has one big... difference...) 2 for the squids, 2-3 for the guns, and 16 copies of the splats (8 positions x 2 colors) The animations for the characters will be standing in 3 directions, (mirroring will be used, and there are only 8 possible directions on the d-pad so 3 copies for 3 directions) walking in 3 directions, shooting in 3 directions, strafing while shooting up in 2 directions (the game will have you start strafing when you start shooting like the real game) (backwards/left could be up/right played in reverse) shooting while strafing diagonally in 2 directions, and shooting while strafing right in 2 directions. Oh yeah, and I'm forgetting throwing weapons and jumping if I ever do that. Yeah, I'll definitely want tentacles to be their own palette so they can be their own sprite and be "free flowing". The ink palette could double as the score board. That gives me 2-3 palettes for subweapons and specials and the tower/rainmaker, and some can take the character and ink palette, like the splat bombs because they're the same color as the ink tank. Holy crap though, there's going to be beyond NES levels of sprite overlays (the hair, the body, the gun, and the ink visible in the gun).

You know, I just thought of something technical. On the one mode I always wrote off as useless (the 8bpp layer with the 2bpp one and offset per column) does it always look for the column offset, or is there a way to shut it off? I think I'll use that mode because I don't want the ink to be 4bpp (takes to long to draw it, and if I want it to look glossy but not screw up, it will take some fancy work on it, but most importantly, the size in vram is too big) but I want the background to be 8bpp because why not. Worse comes to worst, I'll just have it point to a table where the offset for every column has no offset and I'll still save a lot of space.



I'm sorry guys, but I couldn't help myself. I looked up "inkling" on Google images for the reference picture, and this way on the fifth line (not even a tenth of the way down the page) of pictures...
It's amazing how I never found this stuff on the internet when I was younger... Back in the good ol mid 2000's, when people weren't attached to their phones like life support and everything didn't beg for your money.

How do I always get so off topic? I think I have a mental disorder...

A very lame update, but I'm just here to say that I made the palette:
However, you'll notice it's one color too many. I'm split between making the brightest shirt and skin color the same, or having only one shoe lace color (it's the blue color). Or maybe I could compromise with the darkest part of the shoe and the dark red on the ink tank. I find when doing this sort of thing, it's usually better to do it with areas that aren't close together. Actually, I don't really know what's close together because everything is overlapping because you're looking at the character from an overhead view. I probably don't need as many shades of a certain color then because it'll be hard to see fully. Whenever the character is hit with ink, I'll probably only draw the enemy ink on the hair because that'll be less sprites and less animation (the palette for both colors is the same)

I think I'll just draw it with all the colors and then see what I want to get rid of.

Actually, I really just blew everything out of proportion in regards to code. The only real thing that's a problem in regards to 24 bit addressing is this section right here:
This is easy though, as it's just "absolute long indexed with X". (Apparently I got lucky, because it doesn't work with Y?) Because X is 16 bit and the highest possible value is 65536, you'd get 65536, multiply it by 4 (4 2bit pixels make up one byte) and then square root it for 512, so the largest possible map this way would be 512x512 or some variation of that. I'm not sure that that's large enough though.

Apparently, my memory overflow was caused by me being an idiot and doing this:
When looking at the first code snippet I showed you, you'll notice that it's actually starting at InkBuffer, so this is screwed up:
If I just get rid of the "+InkBufferSize", there is no range error. Like I said, I'll probably edit the code to enable a bigger map, but I'm trying to take it one step at a time. I still need to upload the tiles of where the thing is in ram to vram. This is now one of those moments where I'm scared to put it all together and run it because I know there'll be something wrong...

I just realized I quadruple posted... Well, hopefully I'll post again in that I'll get it working.

Espozo wrote:or having only one shoe lace color (it's the blue color).

Considering the shoelaces are going to be a handful of pixels at most (if even that)...

Well, I made the status bar for the most part. It was really difficult to figure out though because out of all the pictures I've seen of the game, only one was actually straight up what the Wii U was outputting and not some blurry garbage.

Anyway...
I made it to where the body palette shares some of the same gray colors from the ink/scoreboard palette for consistency, for I just think it would look nice if the gray in the character was the same. throughout. I know, I'm weird. I changed to orange palette because I originally wanted it to turn more purple latter, but I looked at it on another computer and it was way to vibrant. I don't know if it was just that computer, or if it's mine, but it's not like it's difficult to change the palette latter. Also, I think the "official" way the spots are supposed to be is that they're lighter than the very bottom, but darker than the top, so there's a small area where they aren't to visible. Anyway, I did this and I think it looks better.

Luckily, I have a week off for spring break so hopefully I'll be able to do more. I think I'll try and see if the code works. I didn't want to have it set up to be drawn and have it not work because then I'd freak out and wouldn't have an opportunity to fix it.

I just thought of something... I'm trying to DMA part of the buffer to VRAM, and it has the spot for the bank byte that I filled out with "^", but with the rest of the address, (the other 16 bits) how do I go about this? Just writing "InkBuffer" gives me a range error.

Actually I figured I could just look at the values in ram, but what I found out is that although $7E0000 is supposed to be the start of the buffer because it's the first thing in "BSS7E", there are random, constantly changing values that start right there. I thought that maybe the drawing code was jacked up, but I got rid of the jump to there and it didn't change anything in that the weird values were still there.

I don't know what's up with this either:
Again though, nothing else should be in $7E0000:
I even disabled my object routine to see if that was causing the problem, but it wasn't either. (No objects are actually being drawn, it's just changing the background color every frame. I wanted to see if it properly jumped correctly.)

$7E0000-$7E1FFF is a mirror of $000000-$001FFF. For this reason, the BSS7E segment in my own linker script starts at $7E2000.

Ah, that explains it. I had started to enter panic mode.

Anyway, it doesn't work, but it doesn't crash either (which I've known for a while). It must not be getting to the actual drawing part. I'm really not good at debugging, so this is the part where I just put a brk somewhere and see if it crashes. (To see if that part of the code is even read.)

Okay, this makes absolutely no sense. I was trying to make the SNES freeze to see if it's going there, and I couldn't make it with the drawing code, even when I made the first line that's supposed to be run "brk", so I was seeing if it even approaches the jump and I couldn't even get that to work until I moved the "brk" higher up.

This freezes it:
While this doesn't:
I'm completely stumped. If any of you want to figure out what's wrong, here's the code. It really isn't much aside form the ink drawing code, just a code that identifies objects and jumps to the correct code.

In both cases, the BRK interrupt is returned from immediately, so it doesn't actually "do" anything on its own. The problem is that BRK is supposed to be treated as a two-byte instruction, but cc65 only represents it as one byte in the actual generated code, so once you return from the interrupt, the first byte of the next instruction is skipped and you're basically executing garbage. What happens then depends on what the next instructions are supposed to be.

If you want the BRK instruction to actually freeze the game, you should make it lead to an infinite loop rather than an RTI. Or ideally, use an emulator that supports breakpoints (which it looks like you're already doing) and use those instead.

no$sns will automatically open the debugger on STP. I believe Snes9XW treats it as a breakpoint too. No idea about bsnes-plus; I haven't used it yet...