Two things:
1. How hard would it be to run diff on your source and the original to find out what, if anything, you changed? Were the changes only in the linker lib and the crt0, or something else?
I’m curious about the changes, but if it’s too much trouble, don’t worry about it.
2. That makefile you posted (thanks, BTW!) needs tabs in front of some of the lines. I attached what I think is a correct version.
I don’t have an adapter tap from either country, but I can tell you the following:
The American NES used a standard “barrel plug” on the AC adapter.
The American SNES used a non-standard “barrel-like plug” on the AC adapter. It has a cylinder shaped outer contact, (the positive (+) side) but the inner contact (negative (-) side) is a pin instead of an inner cylinder. (http://www.vidgame.net/NINTENDO/SNES1.html)
The VB will run on anything from 6 to 13VDC (it’s printed right on the bottom…) and draws no more than about 8 watts of power (e.g. 10V @ 800mA) and probably much less.
Looking at the back of the VB pad where the battery box/AC tap connects, the terminal on the left is the negative input (cathode) and the one on the right is the positive input (anode).
Good point, jorgeche. I forgot about that particular use, since DogP mentioned microsecond accuracy (which would not be needed for a 2 second delay) but such a delay could still be based on display frame counting, which allows things like animation and music to continue during such pauses.
The frame rate locking you’ve implemented sounds exactly like what I was referring to. But is it wise to use 60 fps on the VB, which has 50 fps display hardware? Doesn’t that produce visible “jitter” in the video?
Re: Timing
I’m not a game programmer (no matter how much I pretend to be ;-)) but I always thought it was best to keep track of how many display frames have been drawn and base your animation and such on that. For example, if you have a sprite animation that needs to wait 200ms between frames, and your system draws a frame once every 20ms, you would count 10 display frames and increment the sprite frame. To me, this sounds like a perfect way to use the current vbWaitFrame function; except maybe with an added counter variable.
Synchronizing things by making the CPU stop doing anything for a time, even if it’s measured in microseconds, just sounds like a waste to me…
There even exists a thing on the VB that makes “Game frames” out of “Display frames” based on a multiplier. It will even register an error if the VIP takes more than one display frame to render all the Worlds. I don’t know exacly how this is meant to be used, but it sorta sounds like what I explained above…
Like I said, I’m no game programmer. But maybe that’s a good thing 😉
I am behind this 100%.
I think we should start with Jorge’s version and make a standard ELF library and a libgccvb.h which includes other .H files broken down by category.
Then we can update http://gccvb.sf.net/ and use Source Forge’s CVS repository to keep track of changes.
Once we have that established, I encourage everyone who has released a demo to convert it to compile with the new library.
The first thing I want to add is this minimal *printf implementation I found. The included sprintf function can be used with the current vbPrint/vbTextOut functions to output to a BGMap, or an initialization function could be written which automatically sets up the font Chars, a BGMap/World for display, and variables for tracking the cursor position, etc. Thus, printf itself would “just work” as it does on a PC. It could also be used when transmitting data to another VB (or to a PC) over the link port.
After this we could start adding VB-specific versions of other stdlib functions.
I hate to be a stick in the mud, but, what’s wrong with stereo OpenGL on a PC monitor?
Even with free cardboard glasses the picture is better than a VB, and WAAAAY cheaper 😛
I’ll tell you why I still like this project, though: If he gets his decompression routine to full speed and gets anywhere near the needed compression ratio, we could see VB games with FMV cutscenes pretty soon!
Edit:
I thought of something weird:
What if someone made/converted a VB emu to render w/ OpenGL, then ran it through this (when it’s at full speed, of course) on a real VB? 😀 That would have to be a first, even excluding the stereo part.
The only thing that might come close would be watching streaming video from an (Xbox, XB360, PS3) emulator in the browser/media player of said console. And that’s quite a few years off (except maybe old XBox…)
I’m glad nobody reads these comments 😛
I thought I’d take a stab at the math:
On IRC, DogP quoted the link at 235 Kbit/sec, sustained.
One VB screen = 384 * 224 * 2bpp / 8 bits = 21,504 bytes
21,504 * 2 screens * 50 fps = 2,150,400 bytes/sec
2,150,400 * 8 = 17,203,200 bits/sec
17,203,200 / 235,000 = 73.205106 times the link port bandwidth.
That’s quite a compression ratio to shoot for…
I don’t think RLE is gonna cut it 😉
(BTW, I know VEGL doesn’t use RLE; it was a joke :-P)
Wow! Alberto has done a lot to advance the VB dev scene, and I’m glad to see his return as well as a major goal of his coming to fruition.
I’m sure it’ll be doing 50 fps stereo in no time! WOOT! 😀
I already have a cable (mostly) built, too. 😎
Updated code:
#include "libgccvb.h"
#include "chartest.h"
#include "maptest.h"
//Screen is 384 X 224
int main()
{
int objX=0, objY=0;
vbDisplayOn();
copymem((void*)CharSeg0, (void*)CHARTEST, 256*16);
copymem((void*)BGMap(0), (void*)MAPTEST, 256*16);
vbSetWorld(31, WRLD_ON, 108, 0, 76, 0, 0, 0, 168, 72);
VIP_REGS[SPT3] = 0x100;
VIP_REGS[SPT2] = 0x1;
vbSetObject(2, OBJ_ON, objX, 0, objY, 9);
vbSetWorld(30, WRLD_OBJ | WRLD_ON, 0, 0, 0, 0, 0, 0, 0, 0);
vbSetWorld(29, WRLD_END, 0, 0, 0, 0, 0, 0, 0, 0);
vbDisplayShow();
while(1) {
if (vbReadPad() & (K_LR)) objX++;
if (vbReadPad() & (K_LL)) objX--;
if (vbReadPad() & (K_LU)) objY--;
if (vbReadPad() & (K_LD)) objY++;
vbSetObject(1, OBJ_ON, objX, 0, objY, 9);
vbWaitFrame(40);
}
Look in the libgccvb.h file. Those constants near SPTx are used in the VIP_REGS[] array to get the real address.
Sorry for the confusion. (I guess it’s time for another round of updates to the wiki… Unless we change that in the new official library.)
Fwirt wrote:
Actually, to be honest, I did always wonder how they pulled that trick off in those DKC games.
The equivalent of H and V Bias is done on the SNES by using an interrupt that happens on every scanline. When the interrupt occurs, the scrolling registers (among others, like the palettes, etc.) are changed to make waves, etc.
I’m not an SNES dev’er, but I think this is how “Mode 7” effects work, too. (But I could be mistaken…)
Bruno: Fwirt is right; neither H-Bias nor Affine transforms can be used on OBJs. But, the equivalent of “V-Bias” is exactly what Affine transforms are for. One way to accomplish rotation, for example, is to simply shear (think of turning a rectangle into a parallelogram) in first the X direction, and then the Y. When I understand Affine better, I’ll update the Wiki, unless someone smarter beats me to it 😉
Fwirt: Yes, you just have to set SPT3 to the first OBJ you want to show (i.e. the one with the highest number; usually 1023) and then set SPT2 to the one after the last one you want.
Then, you just have to fill in the OBJ data in the right sections of OAM and set a World to display OBJs. I’ve been updating the Wiki again; see if it makes more sense now.
BTW, KR155E, why isn’t there a sticky about the display lines? 😛
Ebisumaru:
DO NOT PLAY THE BROKEN VB, AT ALL, UNTIL YOU FIX IT!
Listen to your eye! It’s trying to tell you that something is wrong!
No long-term studies have been done on this, but it is not worth losing your eyesight or getting migranes or whatever just to play a few games!
Okay, I think that’s enough after-school special 😉
BTW, welcome to the site!
I’m not sure how this post got overlooked for so long, and DogP’s the resident VB display expert, but here goes:
The lines are definitely a loose cable somewhere. The oven trick should fix it right up.
The blurriness sounds like a lens got knocked out of place. Since it’s still in place enough to give a blurry image, it’s most likely fixable, but there’s no way to tell for sure until you open that sucker up. At which point you’ll have the gutted case ready to fix the scratches.
As for paint, spot touch-ups are guaranteed not to look right; and probably look worse than what you’re trying to cover up.
The best thing I can think of is to try to buff the scratches out starting with fairly coarse, say, 600 grit wet sanding, then using progressively finer papers, ending with an abrasive paste like automotive rubbing compound or Brasso polish, and trying to feather it out into the original finish.
Of course, if it doesn’t turn out quite right, you can just paint the whole thing, instructions for which you can find at DogP’s site (http://projectvb.vze.com/).
BTW, I’m glad you didn’t drop your friend on the floor. 😉
Bruno:
You can write to any part of the VIP’s RAM (which includes Frame buffers, Chars, BGMaps, OBJs, Affine/H-Bias tables, and VIP Registers) any time except when it’s being accessed to draw the images displayed on the screen.
Here’s some code from the “vbSetWorld” function:
while (VIP_REGS[XPSTTS] & XPBSYR); // Edit the RAM
(It should probably be in vbSetObject, too… Also, it assumes the VIP is on {VIP_REGS[XPSTTS] & 2 == 2} and if not it will be an infinite loop.)
Fwirt:
1. The VIP does not work in 256 OBJ increments unless you set the SPTx regs that way.
2. It does not start at the “last” one (1023). It starts at whatever SPT3 is set to (it can be anywhere from 0 to 1023).
3. All 1024 OBJs can be drawn in one World; just set both SPT3 and SPT2 to 1023.
4. Check the Wiki again, because I just rewrote the “drawing procedure” explanation.
Hope that helps!
-
This reply was modified 18 years, 1 month ago by
RunnerPack.
It’s basically the same thing slightly rearranged, but you’re quite welcome! 😀
Have you tried the Wiki? If you have, try it again. I just finished editing it for clarity.
DogP’s post notwithstanding, I think there are definite uses for OBJs in a game. A large part of what makes “gamers” (i.e. those whose cable boxes are permanently set to G4TV :-P) ooh and ahh over modern games is the use of particle effects.
Some VB games (Panic Bomber, for one) already feature OBJ-based particle effects and there is no reason they can’t be used to great effect in homebrew, too, IMHO.
Also, as I hope my new Wiki article will show, it’s really not that confusing to use OBJs. Although, for particles and most other uses, I would steer clear of the “SetObject” routine. Using an optimized loop to edit OAM entries directly is a much better idea.
Make sure and post any specific questions if you still can’t get it working.
Have you tried looking in local gaming stores? Even the ones in my podunk town have some, and they’re within your price range. No games to speak of, though…
Actually, IMHO, since none of these topics are of general interest, they should have been PM’s or e-mails directly to KR155E.
Like this… (Koop, check your PM box.)
Then, after the sounds, cursors, and other trivial things are in place, a single post linking to nintendoland.com in the O.T. forum.
I’m just sayin’…
Just port SCUMM VM (http://www.scummvm.org/) and you can have this and dozens of other games.
Of course, the graphics wouldn’t take advantage of the 3D display, but maybe with some changes to the engine and ScummC (http://alban.dotsec.net/7.html) you could make a 3D Mansion (or, even better, Full Throttle or the Kyrandia series ;-))
As for the saving, you could use codes like Gobliiins (another SCUMM game).
I’m sure others have noticed that, when replying, the subject line has a limited amount of space which affects bilingual titles by cutting off the German part and the closing (de) tag.
Not sure how it would be fixed, but the fact that such a long subject can be entered in the first place suggests that it should be technically possible.
A workaround could be to shorten the “new post” subject box to allow for the “Re: ” that gets prepended when replying.