Yay, more fun code to write (job stuff)
I've been told that I tend to focus on the negative. James makes it a pathology. (Earlier today he was also telling the writers how much they should focus on just a single storyline since there's no way they could write all of both storylines within our production schedule.)
The thing that really irked me was that he said, "The IGN reviewers are going to see this, and rate it a 2 because it looks so bad."
When I explained repeatedly that the font was a work in progress (and there was a lot of tweaking potential), most games have historically used an 8x8 font, and it'd take some MAJOR overhauling to use fonts which aren't 8 pixels tall, because of the DS' architecture.
Of course, then James and Antoine both pointed out various gameboy games which use bitmap fonts which aren't 8 pixels tall (that's nice, they're also not doing the same kinds of stuff as us, like they don't have to deal with streaming oodles of animation from the cartridge since all of their character graphics fit into sprite VRAM and so on), and blah blah blah.
Ugh. I was at work until 8:30 PM tonight, and I think at least four hours of that were spent arguing about our graphics architecture (which they blame me for, but it was their design mandates which forced me into doing it the way I did it to begin with). Another three hours were spent "discussing" the issues inherent in 15-bit colors, and how to get the artists to use them (most of that was trying to convince Antoine that there was a problem with just converting the Photoshop-generated 24-bit palettes to 15 bits after indexing the images, too).
The upside of all that was that after things calmed down (which, unsurprisingly, happened immediately when Antoine went home) I was able to take a step back and explain (without being interrupted every 5 seconds with some malformed quips like "well last week you said [thing I didn't say] and [thing I did say taken way out of context]") what the issues were with the architecture, and why we were using the display layout that we were, and then I realized that there was a possibility of doing things another way, and I did some quick tests, and yes, we can.
It'll still be a huge pain in the ass to deal with a few issues which are inherent to making the text size anything other than 8 pixels tall, though, and it'll definitely bring other performance issues to the forefront. But, hey, at least I'm keeping an open mind.
BTW, from TheoEsc's comment yesterday I realized that I should clarify something about this dev team. It is pretty much brand-new, as is the studio; Antoine has been here since February though until now he's only been doing concept and tool development (for a much simpler version of the game which was going to be sold for cellphones), and James and I started at about the same time. As far as the code-side development on this particular game goes, we're all new here. And as far as actual game-related graphics programming experience, I have way more than James. For example, today I showed him a really neat trick which gives you quick-and-dirty profiling with no CPU overhead, and which relies on — and also finally demonstrated once and for all — how the emulator is cycle-accurate (the last three times I thought he finally understood he turned out not to, though it's anyone's guess how long this time it'll last).
One kind of frustrating thing is that it's hard to explain how I know certain things, because neither James nor Antoine seem to have any idea what the demo scene is, or at least what it was when I was part of it, or any of the years and years of experience I have in tricking older hardware into doing neat things which still apply to the current stuff. Like, today I said, "Remember, I've been doing this a long time," and James said, "What, coding on the Nintendo DS?" "Uh, no. Programming raster-based unbuffered graphics hardware, dealing with emulation and timing-level issues, and so on." It still hasn't sunk in to James that graphics programming on the DS is absolutely nothing like programming on DirectX on Windows, but that it is quite a bit like graphics programming on the Commodore 64 and doing bare-metal stuff on DOS, both of which being things I've done for fun for years.
It's pretty difficult to explain how raster effects work to someone who hasn't even had to consider that the monitor doesn't just instantaneously display what's crammed into VRAM.
But, when I explained the quick-and-dirty profiler to him it's like a lightbulb turned on in his head.
For those who don't know what I'm going on about, it's this: Whenever you enter a function, change the palette entry for the background color of the screen to some color which represents that function. As the retrace scans down, the color of the background will change based on which function is currently running, so you can see exactly how much frame time is being taken up by each function.
Sadly, this is a technique which is totally lost on modern-day PC programmers, because modern graphics cards don't even use a palette; as far as they (and the people who program them) care, a palette is just a cheap way to compress a 24-bit texture by 66%.
Speaking of palette issues, that other three hours of discussion was basically because:
- Photoshop will only generate 24-bit colors for indexed mode
- The DS uses 15-bit colors
- 24-bit converted to 15-bit directly looks horrible
- So we need a way of injecting 15-bit colors into the process
Comments
Also does the DS have overscan like the C64 did (more background than what can be displayed)? Or are you just leaving some background space. I assume that the DS screens would be "pixel perfect".