A list of a few of the topics I have played with, and learned a little about:

LARGE projects and build systems

threading

style

static libs


I started this help late jan,2016. It will take awhile.


General:

If you are trying to write a game and use any graphics - the FB graphics library is just too buggy for a large project. Problems include any expectation that threading will always work right. The grfx lib runs with threads that you can't touch. To work correctly with the default console/terminal, the grfx lib has to alter the default behavior of the terminal. This puts your own threads in trouble. Even mutex guards around any of your I/O will not work. What you CAN do is isolate all I/O in one thread. Feed it and send data out of it, but all screen writes and key reads are in this thread. Even double buffering has only one thread controlling who, what, when something goes into or out of the system.

You should NEVER make more than one instance of an fb.event UDT/object. This creates a double-linked list. You will always get an error on close, AT LEAST, if you do this.

SPEED:
Testing for a string is really slow.
Don't: while inkey = "" : wend
instead:
[stringdummy] = inkey
[stringdummy] = inkey
[stringdummy] = inkey
[stringdummy] = inkey
[stringdummy] = inkey
[stringdummy] = inkey
(maybe 5 or ten more times)
The object of the while/wend is to remove any double or lingering extra keys from the keyboard buffer. You can't hit a two keys faster than about 10 ms (usual timing on this about 25 ms.)

Bottom line: your threads and their threads conflict/collide. That is why people use external graphics libraries: predictable.


There has been a problem with the fbc system miss-identifying variables as assembly instructions. To avoid this, try not to use very short (less than 5? 4?) letter variable names, especially any shared variables and those used in a print statement. For small programs, take a chance. As soon as anything shows up, just bite the bullet and go large.


home