I was testing the Putchar Lcd´s routine and I think It´s very handly and work right for my games. Perhaps is not the fastest, but I´m happy with the facilities of modifying its code.

Finally it works now and does not crash in a SUB. I love this routine! It will be included in BorIDE code library.

Just converted the Proportional text routine to a SUB, so it won't crash at exit, but I ran into some problems.
I remember, I asked about it, but the thread was closed then, but you promised to look at this: POKE and PEEK STRING do not work, and something else: @a$ does not return the correct adress of the string stored in a$. It returns a adress, but peeking memory in emulator reveals that the text stored in string is not at the adress. Testing @variable reveals that the adress of normal ubyte variables is correct.
Is this a bug or "feature"? If it is a feature, how to find out the adress of a string stored in Variable?

Hi Boriel, I have noticed that your compiler exits with returncode Zero if no errors was found, One if Errors found, but also One if a warning was generated, and the compilation was otherwise successfull. Can you change this?
0=No errors
1=Warnings, compilation was OK.
2=Error, compilation failed
Or:
0=No Errors or just warnings
1=Error, compilation failed.
The BorIDE does now mark Warning and error lines. It can start the emulator after compilation, but if a warning was issued, it still missinterprets it as compilation fail.

This will put Tiles of 2x2 characters with attributes on screen, and is not restricted to use a particular number of tiles, as it uses a memory pointer to the adress of tile in memory, and it is almost fast enough for games (until someone will write a ASM version)
Note: Lines(23) is used for screen adress calculation. I used only 24 bytes for this table (without bAND function I need a Table for this). not using a array but InLine ASM DEFB data can save 3 bytes.
POKE and PEEK UINTEGER use two-Byte transfer, so this is much faster than transfer of a single byte.
Screen adress calculation is splited (so variable A had to be created) because of a calculation problem. Usualy I would write these lines:

This is somewhat a wish list to which I may contribute (coding my second suggestion).

1.- Types. I'm a nightmare, I keep repeating this, but types are most needed. They would make every coding chore way easier, specially when you have to pass parameters or create arrays of structured data. Game coding can be pretty messing without the ability to create proper data structures.

2.- A nice, fast, simple, hassle-less Putchar (x, y, attr, ascii) function which draws character ascii with attributes attr at coordinates (x, y).

3.- Less important, but may come handy, the ability use Attr as a modifier for Print which combines Ink, Bright, Paper, and Flash in a single command:

I have here a Assembly code for Proportional printing (Created by Odin), but zxb throws it out because of a "Unexpected token '-' [MINUS]" at the line "DJNZ Chr_R2Lp2". The compiler tells me the line, but a minus sign is not present here (this is the bug report). Anyway, this could be turned by our friends here into a nice SUB for the library, once it works, I think. It supports pixel precise printing.
I imported it from Tornado source code using my own importer, I wrote for BorIDE.

A few of you have wondered why I've been obsessing over speeding up math functions, cos the compiler is for games! :-)

Well, here's a concrete example of Fast square roots in action. Part of the football algorithm is "Who do I move, and where?" on the field. I'm hoping for better graphics, but this was a mock up to look at the math of that problem. If a player is moving with the ball, who is nearest to their path to intercept them?

With players all over the place, you have to work out distances to vectors. I finally got this working correctly (it sometimes broke, the last time I looked at this - and it turned out I was crossing the 16 bit number barrier. With a newer, longer sqrt function I can go back and make the algorithm work) and here it is in two versions - one using the ROM sqr() function, and the other using isqrt.bas from http://www.boriel.com/wiki/en/index.php/...:ISqrt.bas - this is a concrete example of why the slow ROM routines can become a problem for certain aspects of certain games. The speed difference is startling. The ONLY difference in the source code is changing the square root used from ROM to library. A matter of a couple of characters and an include.

It picks a point for a ball, and draws the pass line to another player. Then every other player has a line drawn to the nearest point on that line, or the nearest end if that IS the nearest point on the line. But look at the speed difference!

Note: press ENTER for a new screen.

ROM - http://sites.google.com/site/britlion/Passing-sqr.tzx

isqrt - http://sites.google.com/site/britlion/Pa...sqrtLF.tzx

Hallo my friends...

Currently the BorIDE is progressing very good. But Multitab coding is not working yet. I just want to ask if I added ALL available keywords, or are there some missing? Or are some not working?
Commands:
"And As Asm At Bold Beep Border Bright ByRef ByVal Cast Circle Cls Code Const Continue Dim Do Draw Else Elseif End Exit Fastcall Flash For Function Go Gosub Goto If Ink Inverse Italic Let Loop Malloc Multikeys Next Not Or Out Over Paper Pause Pi Plot Poke Print Randomize Realloc Return Stdcall Sub Then To Until Wend While"
Okay, I know! Pi is a constant and not a command.
Functions:
"Abs Acs Asn Atn Chr Chr$ Cos Exp Getkeyscancodes Hex Hex16 In Inkey Inkey$ Input Int Len Ln Mod Peek Point Rnd Sgn Shl Shr Sin Sqr Str Str$ Tan Val"
Assembler (I think, this is complete):
"adc add and bit call ccf cp cpd cpdr cpi cpir cpl daa dec di ei ex exx im in inc ind indr ini inir jp jr ld ldd lddr ldi ldir neg nop or outd outi pop push res ret reti retn rl rlc rlca rld rr rrc rrca rrcb rrcc rrcd rrce rrch rrcl rrd rst sbc scf set sla sra srl xor org defb defw defs defm equ"
Compiler:
"#Include Once"
Types:
"Byte Float Integer Long String Ubyte Uinteger Ulong"
Comments:
"Rem ' "
The latest version recognises now two-word commands like "Continue Do" and allow code folding. There are also different syntax coloring styles for commands, functions, comments and so. Unfortunally SUB clashes because it is available in ASM and in BASIC. Maybe changing the name from SUB to PROC will help, but then it goes away from FreeBasic names...

In library/scroll.bas, the name of the last