Not sure a laser display be very compatible with the raster concept of the VB, however a Vectrex linked to a laser via a Zektor ZVG would be an excellent fit!

(later on)..

OK just read Affines. Seems clear enough. Thanks for writing the doc, David. Although it does raise a question. You mention a new compiler vbgcc/gcvbb; none of them seem to have version numbers so its hard to know whats what, but the one on your site and the one I already have seem to be the same (and are mainly macro based in accessing data.) In your Affine document you provide a nice clear code example which benefits from (what appears to be) very convenient arrays of structures. (WA[31].??? for example. ) I don’t see these structures defined in the include headers I have. Is this what you meant by assisting to rewrite the headers with you?

Cheers Alex

P.S. I take it red alarm uses it’s own direct drawing routines then? I had assumed this was what the (previously mysterious) affine mode was for but now I see that too is bitmap based. Is anything known about the “raw” draw method?

update..

I found a few more hours to look into things. I actually concluded I couldn’t see the wood for the trees! (Shame on me) I found some assembly code and that made a lot of sense to me. (I’ve not done V810 (yet) but it was still clear enough.) So when I brought this knowledge back into vbgcc it all worked great. Perversely I’m finding it easier without the libraries but accessing memory directly (then once I have that working I’m then going back to look at DT’s libs.) So for the moment the standard C it suiting me fine. I have some simple images (VirtualZoa logo) displaying nicely at different depths using BGMs and an OBJ based joypad moveable monogram. Simple but a nice test.

I avoided (affine) Vectors since I’ve been doing vectors on another machine a lot recently, but I guess now I need to complete the VB knowledge set. I’ve just downloaded the affine demo and docs so I’ll take a look and report back. I understand 2D matrix transforms but have not studied affine before. I *think* its all about preserving parallelism (from distant memory) I guess I’ll find your soon enough.

One thing that occurs to me that unlike the “classic” consoles I’m used to the VB has tons of memory and CPU cycles to spare. My head spins when I see the huge BGM tables and many the bytes they consume. (I need to recalibrate!! 🙂 but it’s fun and certainly a contrast. With this in mind I want to be clear on my early projects. It takes time to produce graphics for VB so I want to make sure my efforts are well directed.

Experiments thus far (maybe it’s my eyes) are that the perspective offset alone is a reasonably weak 3D effect. Scaling is an obvious one compliment to it which I’ll be exploring, but the dual aspect sprites may well be necessary. (again that a new, (potentially time consuming) but exciting world to explore.)

A final note. David Tucker- thanks for Reality Boy! Constant EPROM burning was getting tedious, now I can use RB to test things initially, speeding things up a treat. (and the red/blue and interlaced options are very useful indeed!) Ta for such a useful and flexible tool!

Cheers Alex

Update..

I managed to compile hello3.c
Its pretty hard to make sense generally of what routines come in useful when as there doesn’t seem to be documentation to the gccvb libraries and routines. (Does anyone have any?)

Anyway I changed the functions (which turned out to be macros) to some that do exist, although then there were syntax failures. I was really suprised to see a while (false) loop in the macro. So I simplified them to get them to compile, but clearly I’m doing something wrong since gccvb has been around for a while so there’s no way it can be as contradictary as it appears…?? Theories please!! 🙂

If anyone is interested here’s the code I changed..

while (VIP_REGS[XPSTTS] & XPBSYR);
//OBJ_YSET(i, Circle[points*2+1]); // original code
//OBJ_PSET(i, Circle[points*2]); // original code

//OBJ_SET_Y(i,(Circle[points*2+1]) ); // found these macros instead..
//OBJ_SET_P(i, Circle[points*2]); // (but they still fail to compile)
//in object.h macros map to:
//#define OBJ_SET_X(n,x) do { OAM[ (n) << 2] = (x) } while (0) //#define OBJ_SET_P(n,p) do { OAM[((n) << 2) + 1] = (OAM[((n) << 2) + 1] & 0xC000) | (p) } while (0) // simplified macros do compile: OAM[ (i) << 2] = (Circle[points*2+1]);
OAM[ ((i) << 2)+2] = ((Circle[points*2])*10)+100; // added Y movement since parallax is hard to notice.
OAM[((i) << 2) + 1] = (OAM[((i) << 2) + 1] & 0xC000) | (Circle[points*2]);
}

Cheers Alex

P.S. Regarding the flash cart, I said “I made it” to simplify the previous post. I have a wizard friend who actually makes stuff. This was a prototype, but is currently a little awkward to use. He is working on another more convenient version. I guess the dev community (rather than collectors) is a little small at the moment, possibly as it is hard to gain VB programming context. I guess it’s up to him whether he feels it is worth producing more. My opinion would be if a couple more homebrews appear (i.e. we prove VB dev is achievable for the average joe like me) then there is a better case for flashcart production, otherwise they’ll just end up being used to infringe Nintendo’s copyrighted games.. and I doubt any hardware supplier would want to incur the wrath of the big N!

Bingo!

As macallan confirmed padromvb.exe sorted it out nicely!
I can now run the Reality Boy demo on a real VB and more significantly the “example.c” also compiles successfully with gcc to give me a working VB ROM 🙂

Many thanks to KR155E and those of you who took the time to think about this.

I am unable to sucessfully compile hello3.c as it has several errors
“undefined reference – OBJ_YSET” (for example)

Strangely OBJ_YSET is not defined in any of the the include headers..?
So how would I know if it is in the library?

It’s late for me and I have only just stolen 15 mins to test the great tip you gave me, hopefully I will be able to solve the compiling in a day or two with a fresh brain. (Of course if anyone wants to let me know what dozy error I have made in my compiler flags etc.. to save me the time then I’m all ears..)

[Excited to be able to run example.c, but aiming much higher]

Cheers

P.S. Ta for the sound offer, it’ll take me a while to be ready, but I’ll know who to call. 😉

Thanks for the suggestion.
Hmm, Blox 1.1 does indeed work beautifully. (Nice work Christian!)
but what is going on with the others? I notice there are game “headers” at the end of the ROMs and I have also read that they must be in 256,512,1024K sizes..

(I even tried “embedding” one of the other shorter binaries into the 1MB JB and Blox binaries, preservng the game header info. (since much of the “middle” ROM is blank anyway) but as you would expect with such a longshot failed too. 🙂

I guess I will need to try to compile a hello word of my own, but if I can’t get much else to work I would expect it to fail. I must be missing something..

Any more ideas, anyone?