Original Post

one thing i am missing is a consistent library. there are numerous versions of libgccvb floating around, and everybody seems to have his own modified/updated version.
for example, i have just messed around with the source to dogp’s etch-a-sketch, which includes a customized libgccvb with numerous very useful functions and mnemonics, for example for direct screen draw, which can not be found in any other libgccvb version i have seen.

so, to give everybody the best possible tools and to avoid confusion, why don’t we all try to work towards a consistent library with regular releases, always being kept on the latest point of knowledge?

24 Replies

It would be cool, now how can we merge all the versions?, I have made a lot of changes to the library for my project, even separeted the declarations and implementation in .h a .c files to not have link issues.

jorgeche

Even though I haven’t been programming for very long, I did notice that there are an awful lot of libgccvb’s floating around.

I don’t know where you would begin merging them. You could probably start by just taking the most basic and useful functions from all of them, and moving them into one file (e.g. vbSetWorld, vbReadPad, etc.) You could add on more things (like direct screen draw) from there. I need to take a look at that etch a sketch demo…

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.

Hi there, I could post the libgccb I’m using right now, it has some fixes and is now separated in header and source files, that way we could distribute a compiled library, only allowing changes to the committee.

jorgeche

I agree that we should have a standardized library, although I’ve been wishing this for a long time, and unfortunately it may be too late for me. I’ve done WAY too many programs with my personal libgccvb.h, and I’m not particularly interested in changing all my current projects over to a new system, and definitely have no desire in updating any of my old code to work with new libs.

One suggestion though would be to have #ifndef FUNCTIONNAME #define FUNCTIONNAME #endif around every function. This way we could have our own customized libraries #included before this one (with #define FUNCTIONNAME), and they’d override the default libraries. This would be useful for using asm optimized functions, or special requirements for that specific application, or just for laziness of porting from the old libgccvb.h that the app was originally compiled with.

I also agree about printing functions, but I don’t think there should be a printf() function. I think there should be sprintf(), which can be passed to the display function. The VB does not have a terminal output, and shouldn’t be treated like you would running a PC console app. If you have it print to a string, then you can decide what to do with the string, either by writing it to the display using vbPrint() or something similar, or to the link port, or just to memory (like saving high scores).

I also think the ASCII table should be modified from the current 256 char one to just the standard 7 bit 128 char one (with one of the non-printable characters being the blank char so you can have transparent – space isn’t transparent when you have the text “highlighted”). We don’t have unlimited resources, and there’s really no reason to have extended ASCII (or if you really need it, add it in your own specialized lib). I guess the unprintable characters could also be replaced with special extended chars that people may use if anyone thinks that they’d actually be useful.

Another one I hate is the vbWaitFrame() function. This has had MANY different versions, and they all suck :-P. To me, waiting a frame would be a display or game frame. This has almost always been just a delay of arbitrary length, with the exception of a few versions that actually wait a full frame. The problem with waiting an unknown length is that it changes from version to version, and the waits are all messed up… and the problem with waiting a full frame is that it doesn’t give you an exact amount of time that it waits, and it’s also too long for most simple waits (main game loops should be based on this, not short pauses). IMO, we should have an asm function with the proper number of clock cycles counted to get near exact (minus small overhead in/out of the function) to a specified amount of time. Then call the function something like usPause() for microsecond pause (which will always stay at 1us regardless of anything). With an unsigned integer passed to it, we could wait anywhere from 1us to over an hour. I think I even wrote a function like this in asm a long time ago.

I disagree about using precompiled libraries. I like to make modifications to libraries, and especially on the VB, many of these libraries are not optimal, and based on old information (they work well enough, but using new info, they could be made better). I think the headers should be freely available for anyone to modify, and especially to view as a reference… although people should realize that it’s preferred to keep the libraries standard, which is why I think we should use #ifndefs in the standard libraries, and encourage people to make copies in their own headers. That’s another problem with standard libraries is that many of these functions are in their infancy, and you can’t continue to make these things backwards compatible forever when they should have been done some other way.

Anyway, I haven’t seen jorgeche’s libs, but I know Parasyte had logically broken them down into several .h files a while ago, so it may be worth checking those out too.

DogP

DogP schrieb:
I also think the ASCII table should be modified from the current 256 char one to just the standard 7 bit 128 char one (with one of the non-printable characters being the blank char so you can have transparent – space isn’t transparent when you have the text “highlighted”). We don’t have unlimited resources, and there’s really no reason to have extended ASCII (or if you really need it, add it in your own specialized lib). I guess the unprintable characters could also be replaced with special extended chars that people may use if anyone thinks that they’d actually be useful.

right, for us europeans, it would be very useful to have special characters like ä, ö, ü, ß instead.

DogP schrieb:
Anyway, I haven’t seen jorgeche’s libs, but I know Parasyte had logically broken them down into several .h files a while ago, so it may be worth checking those out too.

yep. i have uploaded the lib i am using currently. i don’t remember where exactly i got it from, but it is unchanged for the most parts (i created a pvblib with additional functions instead of modifying libgccvb).

furthermore, i think it would be nice to have a short decription of each function and meaning of the input parameters.

Attachments:

Regardless of the vbWaitFrame function, I’m with you DogP, I found too many problems using it (mainly because it was not properly implemented since a code like this:

while (VIP_REGS[XPSTTS] & XPBSYR);

when using the optimizing capabilities of the compiler, is and infinite loop) that and the delay is completely random.

but i didn’t found a fix until I properly implemented the clock interrupt, now I have a solution, but it is part of my engine which uses the libgccvb, I use a class called Clock, which implements the following method:

//time delay
void Clock_delay(Clock * const this, u16 miliSeconds){
float time = Clock_getTime(this);
while((Clock_getTime(this)-time)*1000 < miliSeconds); } the Clock class has all the necessary information to create a precise delay, so all the Clock's attributes could be expanded as static variables in a c file, but I like to abstract all what I can as a class, and it's is helpul to have more than one clock in a game (more in the vb where you need the automatic pause feature). I like the open source idea, indeed, my own engine will be released with the whole source code, but it could be helpfull if there is a standard library, one which has the memory mapping, register settings and possible values, etc. And functions implementations can remain open. About a character printing system, the way I implemented it is using the vbPrint function: void vbPrint(u8 bgmap, u16 x, u16 y,const char *t_string, u16 bplt); but since in the engine I'm mannaging the bgmap memory I implemented facade functions: void printInt(int value,int x,int y); void printHex(int value,int x,int y); void printText(char *string,int x,int y); void printFloat(float value,int x,int y); and they ask the BGMapManager which is the next free bgmap to use to print text, so this managers keep track of the last bgmap segment used for graphics, and use the next for this kind of printing. I use these functions maily for debugging. I know that there could be a lot better ways to do it, but I like simple functions which do the hard work for me :-). I could post the libgccvb I'm using if someone is interested (but be aware that I use the last gccvb which must be compiled). I almost forget, i have a Textbox class too, which is used to print text but in 3D space, so you can specify the coordinates for the textBox and the engine calculates its parallax, projection, etc. But it is different to the printXXX functions because this kind of text is displayed using a world, and the placement of the text in bgmap memory is optimized. jorgeche

  • This reply was modified 15 years, 10 months ago by jorgeche.

The timer is nice, but it’s a bad idea for delays. Timers are especially good for running in the background while you’re doing other stuff, then you can know how long something has been going. For a wait loop, you want it to block execution until a specific amount of time has gone by. There’s no reason to use a timer when you can count clock cycles and have the CPU run in a loop for that long (plus it’s more precise and accurate). If the standard library mandates that to use a wait you must have the timer enabled and running, then we lose the ability to have control over a really useful piece of the hardware.

About the optimizer causing an infinite loop, you need to change VIP_REGS to be volatile. The old gccVB didn’t optimize that, but the new one does.

DogP

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 😉

Hey, I think I missed the matter, I was thinking about delays which create a pause in the execution of a program, like the ones I use in the boot of my games to not allow the player to pass the logo screens before watching them for 2 seconds, not delay in terms of animation or things like that.

I’m not really sure how to use the in hardware frame counter, but I found how to lock the frame rate of my engine to run at 60 FPS, that way all my animations are based on that measurement, each frame is 1/60 of a second… and from there I can calcultate how much time a frame of animation must live.

jorgeche

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?

Right… I think game animation should be based on display/game “frames” (after you’re done processing that frame, you should wait until the next frame before starting the next), but general purpose waits shouldn’t be based on game frames, because you only have a resolution of 1/50th of a second. Even if you know you want to wait 1/50th of a second, if you just started a new frame, then it’s really gonna be up to 1/25th of a second if you want for a full frame, or down to no wait if you only wait for the next frame. Of course this gets better the longer you wait (you’re always within +/- 1/50th of a second), but like I said, it depends on your purpose of the wait.

If you know you want to wait for the next frame (which really isn’t a delay, it’s more of a synchronization) then you should use the dispaly flags (one of the vbWaitFrame() functions did this). If you know that you want the CPU to stop execution for 37ms (for whatever reason), then the CPU should run independent of anything else and just waste cycles for that period. Another problem of using the display flags is that the display must be enabled. If you haven’t set up the display and wait for the flags, it’ll just be stuck in an infinite loop.

And yeah, typically you won’t need microsecond accuracy, but with an unsigned int argument, that’ll get you from 1us to almost 1hr 12min (which I’m pretty sure NOBODY will need 😉 ). One thing I use a lot of short delays for is for interfacing with other hardware. I don’t care what’s on the display (or if it’s even enabled), but I know I want COMCNT to pulse high for 10ms, or during initialization I have to wait 400us before I can access something, or things to that effect.

So yeah… I think vbWaitFrame() should be deprecated (since it’s been used so much in the past and rarely consistently), and we should have a new function waitDispFrame() or something which waits display frames (argument of 0 waits until the end of the current frame to sync the game to the display), and then another function usPause() which would wait based on a set time delay.

DogP

I haven’t thought about the 50 fps… I will check today how that looks on hardware, but what I did test were 30 FPS and 60 FPS, and at 60 FPS it was a lot smoother than at 30.

About the wait frame, I’m using it before writing world values in the render method of my Map class:

//create an independant of software variable to point XPSTTS register
unsigned int volatile *xpstts = (unsigned int *)&VIP_REGS[XPSTTS];

//wait for screen to idle
while (*xpstts & XPBSYR);

// write the world’ values
WORLD_HEAD(31,XXXXX;

I haven’t used the hardware frame control for anything else.

jorgeche

I just had an idea:

1. Only the most basic things like vbDisplayOn, copymem, etc. could be implimented in a library for fast linking.

2. For the reasons that DogP gave–learning from the code, tweaking things, etc.–a separate .c (and .h) could hold another “layer” of utility functions on top of those, like text output, maybe some affine stuff, etc.

3. It would also be nice to have a set of built-in “warning”, “alignment”, and “Built with gccVB” logo screens–with small ROM footprints, of course.

Also, I know it matters less and less with modern auto-completion and auto-correction of syntax, but what are everyone’s thoughts on the naming convention? I think it’s a little inconsistent right now…

I think it will be very difficult to came with a standard library since a lot of us have made many changes to the common code, for example here is the function I use to read user input, which reflects the need I have with my engine:

/* Reads the keypad, returns the 16 button bits */
u16 vbReadPad(){

unsigned int volatile *readingStatus = (unsigned int *)&HW_REGS[SCR];
HW_REGS[SCR] = (S_INTDIS | S_HW);

// save last pressed key
previousKey = currentKey;

//wait for screen to idle
while (*readingStatus & S_STAT);

// now read the key
currentKey = ((HW_REGS[SDHR] << 8) | HW_REGS[SDLR]) & 0xFFFC; return currentKey; } At work we use the Hungarian notation, and I'm comfortable with it, but personally I like more the notation specified by the Java standard and use it in my personal projects. jorgeche

So I have taken up this task again and am working on compiling a library. I have some suggestions I’d like to discuss with you guys.

1) I think we should rename the library for a unified release to prevent any confusion with the hundred billion and one versions of libgccvb floating around. RunnerPack named libgccvb the “Seiryu” library in the intro text, so I think it’s a good idea to just name the library “Seiryu”.

2) I also think that it’d be a good idea to write short documentations of all the functions.

3) Let’s include a standard font which is automatically loaded to the end of Char Memory when the library is included. That way new users can use vbPrint right away.

4) About the #ifndef FUNCTIONNAME DogP suggested… I am not sure if I did it right, can anyone check the attached files?

Attached are two files which show a proposed format for the library. Comments please, gentlemen. 🙂

That looks pretty good, KR155E. BTW, what tab width do you use? I like four column tabs, myself.

I think the pronunciation of “seiryu” is more like sire-you (which I think I put in a newer local version of the header).

I’ve been sitting on the rest of this post for a few days, so it’s not a direct reply to your post, but here are some thoughts I had after reading VirtualChris’s experiences with the lib and reading this thread again:

1. Let’s assume that the “veterans” (KR155E, DogP, jorgeche, et al.) will not be using the new lib and will instead continue to use and mutate their already mutated versions.

2. Let’s forget about the existing library and example code base and let them coexist with the new one. One or two examples can be ported to/created for the new lib.

3. We can start over and implement everything discussed in this thread in the best (and most future-proof) way we know how based on the current state of VB knowledge, which includes (IMO):

a. Making (at least two) layers of functions:

i. The basic, low-level stuff (switching on/off the display, copymem, etc.) can be in a static library because it won’t change much, if at all. It should also be optimized as much as possible (asm, etc.).

ii. The utility functions (fading the BRT regs, reading the pad, etc.) should be as now (except split into a .C and a .H) so that they are optional. This layer could also exist in multiple files. They should be optimized, but not at the expense of readability. It goes without saying that every “layer” should be commented profusely.

b. Wrapping functions in #ifndef’s to allow overriding by the user (especially useful for the dummy interrupt handlers).

c. Fixing/standardizing the synch/delay stuff, etc.

d. Unifying the notation scheme, tab size, formatting, etc.

e. Adding dasi’s sprintf and standardizing the font situation (esp. W.R.T. handling international characters).

f. (Optional) Selecting and optimizing a set of affine-transform functions, sound functions, etc.-basically anything that seems handy.

g. (Optional) Designing non-copyright-infringing default warning and adjustment screens.

h. Discuss and add to this list…

I think the pronunciation of “seiryu” is more like sire-you (which I think I put in a newer local version of the header).

If this is thought to be Japanese, then most definately not 😛

It’s more like Say-roue or something. However, I really hate writing pronunciations with other alphabets…

The “ei” is a long e. If you pronounce “sire” that way… o.O” The ryuu does not go to a “ri” first (that’s “ri” as in elementary, not as in rye!) but goes down almost immediately after the r sound, which also sounds different from English >:P

cYa,

Tauwasser

D’oh! I was thinking of the German diphthong “ei”…

Here is a good page for Japanese pronunciation: http://www.fonetiks.org/sou3ja.html

That looks pretty good, KR155E. BTW, what tab width do you use? I like four column tabs, myself.

Thanks! I use a tab width of two whitespaces, which is the standard UltraEdit uses.

You have a lot of good points there. Not much to add.

Unfortunately, I have too much other stuff to do at the moment, so I attached what I had so far. Not much, but something. 😉

Attachments:

 

Write a reply

You must be logged in to reply to this topic.