HorvatM wrote:

rubengar wrote:
and other cuestion because the caracter looks bad to go through the background!!

I might be wrong, but I believe it’s because it has black pixels.

Actually, the Virtual Boy is perfectly capable of displaying solid black, but you have to be careful, because there are two different “blacks.” If you set one of the pixels in your char to binary 00, that’s actually the code for a transparent pixel (but it will look black on a black background.) In order to get true black, you will have to change one of your palettes to include solid black, then set the bgmap to reference that color. For example:

    VIP_REGS[GPLT0] = 0xE0; // 0b11100000

will change any cells in your BGMap using palette zero (the default) so that “dark red” (0b01) is now black. Make sure to put that statement after vbDisplayOn() if you want to try it, as vbDisplayOn() resets all palettes to 0xE4 (0b11100100).

mbuchman wrote:
You are right, no speed advantage with modern compilers. Plus, even if it was a dumb compiler and did use a few extra clocks, who cares?

A few extra clock cycles can make a big difference in timing critical situations! What if it was the difference between finishing your polygon drawing routine and having to wait another frame? Of course if it was that critical you would probably be writing assembly, but still…

[Fwirt]

HorvatM wrote:
Maybe his libgccvb.h #includes them, so he doesn’t need to bother with it. That’s what mine does.

That’s what mine does too, actually. I guess I wasn’t thinking… :-P. I assumed that he had the single file one because when I started programming that version was all that I could find.

HorvatM wrote:
Also, why do you use for(;;) instead of while(1)? Is there any advantage, or is it just a stylistic choice? I believe that the compiler will recognize 1 as being always true and will not generate code to test the condition.

RunnerPack suggested that to me. I always used to use while(1) because I thought that was correct (and I still think it’s more readable) but RunnerPack suggested that for(;;) was a tiny bit faster. Now that you bring it up and I did some research, I’m not sure if that’s actually true (maybe someone knowledgeable can tell me either way?)

rubengar wrote:
what is the error?? the screen goes black when I include more documents. h!!!

I’m sorry rubengar, I don’t understand… Do you mean that when you include a file called “documents.h” your screen won’t display anything, or do you mean that if you try to include any more files in your program, your screen blacks out? Either way, unless you’re changing something in your main function, it shouldn’t be affecting your display… (Unless you’re running out of memory somehow?)

EDIT: I just made a quick C program:

int main() {
    while(1);
    //for(;;);
    return 0;
}

…to test the while vs. for thing and compiled it twice (once with the for commented out, once with the while commented out) with gcc -S to generate an assembly listing. It came out the same both times. So they are functionally equivalent then. There’s really only going to be one infinite loop in your program anyway, but I guess you can choose which way you want to do it without speed concerns…

• This reply was modified 14 years, 2 months ago by Fwirt.

[Fwirt]

Rubengar, I took a look at the code you posted (capitan.c) and I tried to make it easier to read and give you some tips in the comments. Other than some minor readability issues, it looks pretty good. If you want an example of moving a character around on the screen, check out demo 2 in that folder of 6 demos I posted. Also, I would recommend switching from the single file libgccvb to the more complete version that’s spread over multiple files (that’s also in the folder with my demos.)

Tambien, no te sientas mal de su ingles… Deseo que hable espanol como te hablar ingles!

• This reply was modified 14 years, 2 months ago by Fwirt.
• This reply was modified 14 years, 2 months ago by Fwirt.

Sorry this doesn’t solve your problem Fire-WSP, but thanks so much for bumping the thread! The left display on the Virtual Boy that I use most frequently went out AGAIN a couple weeks ago, and I was trying to fix it last night. Since the oven method had never really worked for me, I was trying putting a paperclip across the ribbon cable where it joins the display and heating it with my soldering iron to remelt the plastic to the board. It was only sort of working… the display I had “fixed” still had red lines… (But at least I got rid of the image ghosting.) I had seen DogP’s NaOH method, but I didn’t really want to risk my displays by having to rinse the stuff off, plus I’d have to go buy the stuff and some way to heat it since I’m sure use of our oven for that would not have been approved. After this thread was bumped, I crawled it really quick for solutions and saw mbuchman’s video and well… I’m a believer in it now! The left eye display came out working flawlessly on the first try. The right display took two tries, and a few lines are dead, but it was that way before I started, so at least I’m no worse off. (I think that some of the LEDs might just be fried.)

Since I’ve done this now, I can give some pointers: the iron doesn’t even need to be fine tipped, I just used the stock tip that came on my Aoyue 937+. (Which is an iron I highly recommend BTW.) As long as you let the solder blob do the work, don’t touch the cable with your iron, and only move the iron parallel to the cable you should be fine. The temp I set my iron for was 300°C, or about 550°F. I found that “scrubbing” the solder blob back and forth from the board up onto the cable a bit worked the best for removing the plastic coating. (Note that when I say scrubbing, I was not letting my iron tip touch the material, let the liquid do all the work. I’m sure if you actually scrubbed with the iron you would damage the copper.) They did come out looking pretty ugly, but as long as this fixes the problem for good, I’m super happy.

One question though: should I worry about cleaning off the flux from the solder? Will flux that’s left on there eat through the copper eventually?

I don’t think it’s so much 10% taller as it is 10% less wide. The displays are a fixed height, it’s the scanning motion that affects the width of the pixels… At any rate, if you do some kooky stuff with the aspect ratio, you might just end up with a headache.

akumie wrote:
how do you open the demos
I tried to rename the makefile and the c file to .vb but no look
maybe you need a program to add the cod before viewing it?

What’s your programming background, akumie? It sounds like you haven’t compiled any C before. If you’ve never done any programming, I don’t think that my demos are the best place to start… With that being said, to view the code you can open it in any text editor. (I use vim on Linux, Wordpad on Windows will do.) To run it in an emulator is an entirely different thing. You’ll need to get gccvb, then open a terminal, navigate to the folder of the demo you want and type “make” (Assuming you have make available to you, it’s available on Unix-like operating systems, or if you have Mingw/MSYS installed on Windows.) That will compile it into a .vb file which can then be run in mednafen or Reality Boy. (All of these demos were compiled using gccvb4, and tested in mednafen.)

I’m glad there’s been such a positive response! Let me know if anyone runs into problems with my code…

Sounds kinda like Robotron 2084… (Which would make excellent use of the D-Pads BTW)

Honestly, I would decide on what _kind_ of game you want to make before you think “3D” or “Robots”. Platformer? RPG? Shmup? It’s also good to have some experience under your belt before you run off and try to make something as complex as a polygonal 3D game. A Tetris clone makes an excellent first project.

Thanks for the tips DogP. This is what I get for spending the last couple years working almost exclusively in Java. I guess I just need to think at a lower level.

Derr, thanks DogP, I didn’t know I had to pass pointers, I was trying to pass the structs by value. Changing that solved my problem. Is there a particular reason we can’t pass by value? For example, right now I have a procedure that does this:

void add_ship(ship);

void add_ship(ship i) {
    ships[end_ship] = i;
    end_ship++;
    if (end_ship > NUM_SHIPS-1)
	end_ship = 0;
}

(On a side note, I didn’t realize until earlier today that malloc() didn’t work, so I’m doing some kind of hackish queue implementation with an array) I really have done more C++ stuff than C stuff, so I’m not exactly sure what to do here if I can only use pointers… I tried looking into passing by reference earlier and I guess C doesn’t have that. (I probably should know this…) I also thought I could just dereference the pointer, but that gave me the same memcpy problem. Is the only solution something like:

void add_ship(ship*);

void add_ship(ship *i) {
    ships[end_ship].x = i->x;
    ships[end_ship].y = i->y;
    //Etc...
    end_ship++;
    if (end_ship > NUM_SHIPS-1)
	end_ship = 0;
}

Ship has a lot of fields in it, so I’d rather not go about it that way. Do you have a better way to do this?

Okay, I just ran into a really annoying bug, (especially with the compo deadline right on the horizon.) I finally got the chance to spend a few hours coding today, and after working all the minor kinks out of my code, I tried to compile… and got this mess:

/tmp/ccexA19C.o: In function `_collide':
main.c:(.text+0x1a8a): undefined reference to `_memcpy'

There’s more of that pertaining to several other functions, and I’ve reduced it down to the fact that it’s affecting all of my functions that take a struct as a parameter. I’m assuming this is a glitch on the compiler end… Does anyone have any tips? I guess this is is my fault for not testing out structs earlier…

I meant to comment on this when I saw it a couple days ago, but I guess I forgot to hit submit. That evil jellyfish (er, you said it was an octopus?) reminds me of Evil Otto from Berzerk. 😛 It’s pretty fun, I quit around level 6 when the anaglyph glasses started to hurt my eyes. The one problem I had was with the foreground/background thing. I haven’t played your latest version, but in the last one it was really hard to tell whether I had to be in the foreground or background to avoid walls. Like you said, maybe it would work better on a real VB.

I haven’t even gotten my engine working yet… I guess this entry means I’ll have to pick up the pace! 😀

I don’t know, at least that one doesn’t look like it could make the VB chase you across a wasteland so it could take your eyes…

A few hundred US? You’ve gotta be joking. Prototype or not for me it’d be $50. That almost looks like something you could make yourself out of some PVC and a broken VB stand.

Seriously, what is most peoples’ problem with the VB? I was driving home with a friend the other day and we got on the topic of the VB somehow, and the conversation went something like
Him: “Man, that was the worst system ever, I wish Nintendo had never even invented that.”
Me: “Um, I own 2, and they’re pretty amazing. You’ve never even played one.”
Him: “I don’t need to play one, I know it was awful.”
Me: “…..”

On another note about the article, I think it’s funny that they used a giant bloodshot eye to represent the VB. What is it with people thinking the VB hurts your eyes? Modern 3D has exactly the same capacity to do that and you don’t hear people whining about it.

It looks like all the controllers for those dead VBs just went up http://cgi.ebay.com/Virtual-Boy-Lot-11-Virtual-Boy-Controllers-/320588194003?pt=LH_DefaultDomain_0&hash=item4aa48ba0d3#ht_6151wt_913

Vaughanabe13 wrote:

Affordability is always going to be a problem with this kind of cart, unfortunately. The VB technology is really old and the components are rare and expensive. The board costs won’t be so bad if there is a high enough demand, because I can make large batches of PCBs and get a discount that way. It all depends on how many people are interested in something like this. I can’t imagine I would be able to make this cart any cheaper than $60-70 USD but it’s tough to say. Again, I don’t care about making a profit or anything. I might even put the designs and firmware out there for DIY people who want to order their own board and components.

Open source really is the way to go. I like how the PVBCC is going open-source this year so we can all learn how the pros do such cool stuff ;-). Actually, I’ve always wished for schematics of the FlashBoy, just to see how it works and if I could make a clunky similar solution. I’m a computer science student (who wishes he could’ve studied computer engineering 😛 ) but I do some hardware hacking as a hobby, so I’ve played with microcontrollers, nothing as professional as that board layout you’ve got there though.

And I can’t believe you don’t want any profit, at least throw $10 into the total cost for yourself, man.

Vaughanabe13 wrote:
Does anyone have the dimensions for a (original) gameboy cartridge off hand? I know it’s not the same as a VB cart but they are plentiful and I could potentially hack it and try to make it work. I personally don’t care about having a case for the cart, but I understand it’s an issue that needs to be addressed.

No dice, VB cartridges are way thinner than GB carts. In fact, VB cartridges are just about the thinnest carts I can think of. You can fit a VB cart inside a Game Gear cart carrying case, unfortunately you have to rotate it 90-degrees so that wouldn’t work either. (Plus the fact that Game Gear carts are getting to be somewhat of a rarity too.) Personally, I’d be fine with a bare PCB, but from MineStorm’s comment, I would guess that that isn’t true for everyone else.

On a side note, I didn’t notice this thread when you posted it, really nice work dude. I probably wouldn’t be able to afford this any more than a FlashBoy (or an EPROM cart for that matter) but I was always wondering, “How would you go about making an SD cart?” I’m glad someone has the engineering skills to get it done. What are you getting your degree in?

My understanding was that the badly spaced data on the disk would cause the drive motor to burn out faster from doing so much seeking, not that the laser would fry. Unfortunately, I think all we buy is cheap CDs. 😀 It’s also possible that, like DogP said, some consoles wear faster than others. I see DRE Gamecubes turn up in local thriftshops all the time. Funny story, my current Gamecube is one I got for $3 that I cranked up the power on to squeeze a little more life out of it, having traded my good Gamecube for my Dreamcast… At any rate, since I don’t play backups and only really have 1 burned game anyway, I probably just shouldn’t fret about it.

Raverrevolution wrote:

gunpeiyokoifan wrote:

Fwirt wrote:
Also, there’s a freeware homebrew game for DC that you can download and burn called dRxLaX

I want to avoid CD-R games since I hear it burns out the laser causing it to slowly die 🙁

I used to burn games all the time and played them straight up and I can tell you first hand that yes, it does kill the laser badly. I ended up replacing the laser and now my launch console still works good.

Yeowch! Better stop playing that then. I’ve only booted homebrew a few times, but I’d like to keep my Dreamcast functioning as long as possible. I recently got Fatal Fury: MotW fro someone who swears it worked on their Dreamcast, but I can’t get it to play on mine. I hope this isn’t the cause! Thanks for the tip!

You’re kidding me, no Bangai-O on that list? If you like shooters, don’t miss that one… (I even have an extra copy you could buy off me 😛 ) Ooh, and pick up a copy of Space Channel 5 while you’re at it. Also, there’s a freeware homebrew game for DC that you can download and burn called dRxLaX which is a lot of fun if you can round up 3 friends (and 3 more controllers.) And that doesn’t even scratch the surface of all the Naomi arcade ports for the system… My Dreamcast is probably my second favorite console, right behind my SNES (Sorry RunnerPack, I think it beats the VB by just a smidge 😉 ).