HP Lovethrash wrote:
Great looking site so far! I’ve mentioned before that I’m (clearly) a big HP Lovecraft fan, I’m glad the Virtual Boy was honored with a game loosely based on his works.
Thanks. For me, the game was an introduction to his works.
This may be a dumb question, but does your editor allow for adjusting how many hits you can take?
The editor only modifies data (not code), and only some kinds, but it can include IPS patches generated by other programs to modify other data and code.
It is very easy to change how many hearts you can pick up, but the HUD only shows 5 (modifying that would require larger changes and I don’t know how it works yet). I’ve attached a patch that raises the limit to 10, and also one that changes the starting health to 5 hearts. You can use both at the same time.
With that editor utility, one could almost see a PlanetVB original sequel at some point in the future!
Yes, that would be great. Maybe you should start a thread about it.
Also, Benjamin Stevens should be releasing a new set of levels in 2 weeks:
Maybe the gccVB startup code should clear the VIP RAM. While I like to keep things minimalistic (so in my opinion it shouldn’t initialize the column table; that’s vbSetColTable’s job), it does clear the WRAM and forgetting to clear the VIP RAM is a really easy bug to make. In fact, I’ve never cleared it in any of my projects (even though I’ve encountered the bug) because I always forget to.
Indeed, that would be quite simple. I suggest you use my program VBIMGC to convert the animation frames into VB format (note: you will have to use a batch file or something because it is not really designed for full-screen animations like this).
The tricky part would be getting the animation to fit on a 2 MB FlashBoy. If there aren’t many frames and/or the resolution isn’t very high, you might get away without any compression (the VB should be fast enough to load frames in real time). If the frames contain areas of repeating 8×8 patterns, then RLE would be a good choice because it’s simple and fast to decompress.
The engine should be able to play up to 5 sounds at once (see kMaxSounds in su11sfx.h). You are probably somehow calling PlaySound on the same sound more than once, which just uses up extra channels for no reason.
The text is OK, but some of your data is incorrect.
There isn’t that much RAM. According to Nintendo’s development manual (pages 2-3-2 and 2-3-3), there’s 1 Mb (megabit – that’s 128 KB) of video RAM, 1 Mb (128 KB) of DRAM, and 512 Kb (64 KB) of “pseudo-SRAM”. But if you add up the numbers on page 5-5-2, the VIP only uses 224 KB(?). The WRAM (“work RAM”), in any case, is 64 KB.
The sound is 10-bit when it hits the speakers, although the mixing process uses various levels of precision (between 4 and 13 bits) in different stages.
Where did you get the sales numbers from? That’s really interesting, I thought the VB was much more successful in North America. (If the VB sold better in Japan, there why is there no Japanese equivalent to PVB? Or is there?)
And we really need a better picture of a full VB setup, one that doesn’t have terrible lighting and has the stand set up correctly. Do we have any photographers on this site?
Benjamin Stevens wrote:
Speaking of which, there is currently a CIB copy of Mansion of Insmouse sitting at about 17 bucks, and its going to end in about 11 hours:
Yes, he was obviously very “inspired” by AVGN. Everyone I’ve showed Red Alarm to has been very impressed by the depth. And Wario Land being #1 was very predictable.
I have experienced a DK1 and DK2 and I agree with DogP that it feels like sitting really close to a TV, especially on the DK1, where you can easily see individual subpixels. The LCD is hard on the eyes and you can get motion-induced sickness really fast, but that of course depends more on the software than the hardware.
I’m surprised there isn’t the same amount of myths/criticism/superstition surrounding it as the VB, which, IMO, is for now simply a better product. Maybe because it’s got John Carmack behind it? Gunpei Yokoi apparently wasn’t a good enough celebrity.
cr1901 wrote:
Just wondering- has anyone attempted to compile and link against the github-host libgccvb using GCC 2.95 or another version besides GCC 4.4?
It compiles and links fine with GCC 2.95.2 (or at least it seems to in the simple test I used). However, it complains with “video.c:26: warning: `/*’ within comment”.
In particular, the SOUNDREG and WA structs quite possibly will not work as is. Since compilers tend to add padding to speed memory accesses up, and both the listed structs depend on having no padding whatsoever, I’m a little surprised that they work at all.
SOUNDREG contains explicit padding, and everything is byte-sized. Everything in WA (WORLD, actually) is halfword-sized, and it’s a power of 2 in size, so what’s the problem?
Additionally, there are a few GCC extensions used in the code, particularly inline, asm- these can be conditionally defined depending on the compiler used. I do not know what extensions to ANSI C that VUCC supports, but I highly doubt it supports all of GCC’s extensions.
I don’t see the inline keyword being used anywhere.
As for inline assembly in VUCC, if you search for “asm” in CGRIND.EXE with a hex editor, it seems to support it, as well as literally implement Greenspun’s tenth rule. 😛
The signature of main() also differs between VUCC (void main) and GCC (int main). Since they’re both freestanding, neither of them are wrong (ANSI says it’s compiler-defined), but perhaps a macro could be defined which uses one signature or the other depending on the detected compiler?
cr1901 wrote:
Is a Unix or source release possible for those who do not use Windows?
What OS do you use?
I’ve been batting this around, but at least for my project, it may be beneficial to include the raw assets, and have the build system convert them to tilemaps as a “preprocessing” step before compilation, but I’m not sure.
I’m open to suggestions. In particular, if you mean the listing file idea discussed a few posts ago, suggestions would be really welcome, because I’m not entirely sure myself how it should be implemented.
cr1901 wrote:
(including up to 7 pixels off the left of the screen- not sure if this applies to the right of the screen, can someone confirm this?)
Yes, and in fact at least 32 pixels off-screen in any direction. The X and Y coordinates are 16-bit anyway, so even larger numbers shouldn’t be a problem.
This means that to create larger sprites, objects need to be combined together at offsets of 8 and moved simultaneously when movement should occur. Animations can also occur by swapping the character index field of the object attribute memory, of the relevant characters at each frame. Do I understand this correct?
Yes.
This is what confuses me: Compared to drawing backgrounds, drawing objects is slower and requires more ROM space.
Why would it require more ROM space? The character format is the same and the last halfword of an object is the same as a BGMap tile. So you can store a sprite as a BGMap and (manually) convert it to objects when displaying it.
Animations can be accomplished by swapping out character memory each frame.
Or changing the world’s MX/MY/MP properties, which is much faster. You just put a sprite sheet on a BGMap.
In practice, is there any reason to draw sprites using objects instead of reserving backgrounds, which should be faster, when a limited number of foreground sprites should be displayed?
Yes, if you need many small sprites, like bullets in a shoot-em-up, or in any situation where you need more sprites than worlds and BGMaps allow.
Will drawing 1024 objects set the “draw time exceeded” VIP status?
I don’t know, test it. 😛
Lastly, the official development manual has the following to say about object control registers (page 5-9-2):
I can’t help you there, but the official manual is full of little errors like that, so that might be an error too.
Seriously, I’m almost comfortable with the hardware. It only took me about 1.5 weeks too! 🙂
That’s great! It took me much longer (and there are still things I haven’t explored yet).
