compilador separado

[sindecencia]

Hola Boriel
Perdona que escriba en español, pero mi inglés es malísimo.

Más o menos lo que te dije por twitter. Ya que la versión compatible con Sinclair Basic no sería muy útil, sí que se podrías sacar una versión extendida más simple. Se que es mucho trabajo y no te vas a poner después de 2 años, pero ya que es una idea te la comento.
-Quitar el tipo Float Point y todas las rutinas asociadas.
-Simplificar el parser. Por ejemplo impidiendo etiquetas con números y obligar los dos puntos detrás.
-Nuevas librerías de sprites: puedes usar las mismas del z88dk.
-Usar un modo de compilación que no dependa de la ROM. Para este modo los programas serán más largos pero por ejemplo puedes hacer juegos compatibles con interfaz 2.
-Permitir compilar en los primeros 16K. Esto es útil para juegos en cartucho o para usar los modos especiales del +2a y +3.
-Usar el doble buffer. Esto es para modelos +2a y +3 que disponen de video shadow (creo que puedes alternar la página 5 y la 7 como memoria de video)

[LCD]

Perdona que escriba en español, pero mi inglés es malísimo.

What does stop me to post in german?

-Nuevas librerías de sprites: puedes usar las mismas del z88dk.

I think, sprites are planed for later version

-Usar un modo de compilación que no dependa de la ROM. Para este modo los programas serán más largos pero por ejemplo puedes hacer juegos compatibles con interfaz 2.

The compiler does not rely on ROM, but on own set of routines. I have not tested it, but I think, if will work from Interface 2 ROM, but only if the workspace is set to RAM and not ROM

-Usar el doble buffer. Esto es para modelos +2a y +3 que disponen de video shadow (creo que puedes alternar la página 5 y la 7 como memoria de video)

It is possible to set different drawing buffer in last versions, you just need to page it in.

[boriel]

LCD: How did you understood what sindecencia wrote??? hock:

[slenkar]

google translate?

it does a good job

[LCD]

LCD: How did you understood what sindecencia wrote??? hock:

Not all of it (I did not use automatic translation), but most of the texts is understandable. I must admit: I understand many languages. Some better, some less, but I'm not able to WRITE in them. I have downloaded some spanish retro magazines and learned a bit to understand them, as google translate cannot translate PDFs yet (?)

[sindecencia]

Hello LCD

Thanks for your answer. I have discover the compiler recently and I am impressed. When I talk (with twitter) with Boriel, my main suggestion was to separate the compiler, as FreeBasic does:
1. One compiler for compatibility with Sinclar Basic (line numbers)
2. Another compiler improved, with sintax similar to FreeBasic (without line numbers)

But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.

So my main suggestion is make the 2 option, avoiding slow FP ROM routines. Use fixed point instead, there are some algorithms <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/CORDIC">http://en.wikipedia.org/wiki/CORDIC</a><!-- m --> than are focused in hardware without arithmetic multiplier.

About the double buffer, my idea was make it transparent to the user. So for example you write Circle 100, 100, 10, and the compiler writes the circle in the back buffer, and flip the buffers when completes, avoiding flickering.

[LCD]

Hello LCD

Hi sindecencia

Thanks for your answer. I have discover the compiler recently and I am impressed. When I talk (with twitter) with Boriel, my main suggestion was to separate the compiler, as FreeBasic does:
1. One compiler for compatibility with Sinclar Basic (line numbers)
2. Another compiler improved, with sintax similar to FreeBasic (without line numbers)

But who really needs line number? Okay, to compile old existing programs, but as ZXBC already supports line numbers, it just only needs a switch to tell the compiler, "Compile in legacy mode", so it will not need "END IF" anymore. That will be okay, but splitting the compiler and work on two versions is too much, I think.

But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.

I support Boriel 100% with this decision.

So my main suggestion is make the 2 option, avoiding slow FP ROM routines. Use fixed point instead, there are some algorithms <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/CORDIC">http://en.wikipedia.org/wiki/CORDIC</a><!-- m --> than are focused in hardware without arithmetic multiplier.

Maybe only as option because most coders use integers only, with rare use of FP. Adding Fixed Point library will blow the code up, and if it is rarely used, it makes no sense to replace all the routines, because if FP is rarely used, the speed does not matter that much, but wasting some of the 41 Kb free memory will kill some projects. This is my opinion.
I already suggested to give the user switch to control which Runtimes the user want to use: "ROM Routines" for slow but small programs or "Custom routines" for fast but larger programs.

About the double buffer, my idea was make it transparent to the user. So for example you write Circle 100, 100, 10, and the compiler writes the circle in the back buffer, and flip the buffers when completes, avoiding flickering.

The user needs full control about the 2nd screen. Transparent buffer is maybe good for sprites, but I do not like the idea. If every graphics command will switch the buffers, drawings will apear faster, but for EVERY object! You will see the drawings appear line by line by circle. With present system you can draw complex figures in backbuffer and then switch the screens. If there should be a backbuffer, so I propose following commands:
SetBackbuffer nr,address,mode - Sets the address od a backbuffer (maybe continuous memory as on SAM Coupé, which can address 512 KB, this will be also good for other planed supported plattforms), mode only for other systems where screen modes use different bytes count.
DisplayBuffer nr - Displays a buffer number
UseBuffer nr - Uses Buffer for drawing
SwapBuffer - Swaps tho hardware Buffers (on 128K), changes other Screen to be viewed and Use Buffer to the now invisible screen automaticaly.
Or something similar, but on the other side, nobody stops me to write Subroutines which will do that for me.

Greetings.

[slenkar]

im used to dealing with sprites and the backbuffer, so those commands sound nice

im used to using these commands like this:

'mainloop
while not endgame
cls 'clearscreen
drawsprite alien,x,y
drawcircle x,y,width
plot x,y
drawline x,y,x2,y2
flipbuffer
wend

[boriel]

im used to dealing with sprites and the backbuffer, so those commands sound nice

im used to using these commands like this:

'mainloop
while not endgame
cls 'clearscreen
drawsprite alien,x,y
drawcircle x,y,width
plot x,y
drawline x,y,x2,y2
flipbuffer
wend

Almost all of these are already supported except the flipbuffer routine, that should be created in a separated library/xxxx.bas file and the sprites libraries. Several sprites projects has been started and discused in the forum (eg. the fourspriter, the putchar, and other). Fourspriter is a 16x16 sprites library created by The Mojon Twins, which has been ported to ZX Basic (with permission). :-) Other libraries might come later...

Not sure if you knew Sinclair Basic (e.g. drawcircle primitive is CIRCLE).

[sindecencia]

Almost all of these are already supported except the flipbuffer routine, that should be created in a separated library/xxxx.bas file and the sprites libraries. Several sprites projects has been started and discused in the forum (eg. the fourspriter, the putchar, and other). Fourspriter is a 16x16 sprites library created by The Mojon Twins, which has been ported to ZX Basic (with permission). :-) Other libraries might come later...

Not sure if you knew Sinclair Basic (e.g. drawcircle primitive is CIRCLE).

I think the flipbuffer routine must be flexible.

-Must allow, optionally, the copy to the backbuffer.
If you generate the entire frame from stratch has no sense this copy, but if you draw a circle, apply flipbuffer and draw another circle, without copy the first circle can't be showed.

-Has more sense to be allocated in a interrupt that directly on code.
If not, you can flip in middle of a frame, and show up the upper half frame from backbuffer and the lower half from the other buffer. Also is desirable that you can configure the frame skip. If you can draw a entire buffer in 1/50 second, perfect (flip every buffer). But normally, and specially on smoth scroll games, you
need 2/50 or 3/50 seconds (25fps or 16.7fps).

[boriel]

-Has more sense to be allocated in a interrupt that directly on code.
If not, you can flip in middle of a frame, and show up the upper half frame from backbuffer and the lower half from the other buffer. Also is desirable that you can configure the frame skip. If you can draw a entire buffer in 1/50 second, perfect (flip every buffer). But normally, and specially on smoth scroll games, you
need 2/50 or 3/50 seconds (25fps or 16.7fps).

Almost none (if any) of the Speccy games work that way. The Z80 on the Speccy run at 3.5Mhz, and it's almost impossible to redraw the entire screen at 50fps. Mostly games just redraw tiny screen portions, and if the got more than 10fps they were considered Ace games. E.g. Alien 8 runs < 10fps for sure (jump over a platform and you will notice it). Remember screen memory is "contended memory" (slower) than ram above 32767 (32K)

The Spectrum 128k allows screen switching with a single out instruction (which can be directly done in ZX BASIC). So I guess the fastest strategy is to predraw both frames and only draw changes in both of them, swiching them with an out. Not sure if any game used this technique, but know there were games which used the alternative screen memory address.

[sindecencia]

But who really needs line number? Okay, to compile old existing programs, but as ZXBC already supports line numbers, it just only needs a switch to tell the compiler, "Compile in legacy mode", so it will not need "END IF" anymore. That will be okay, but splitting the compiler and work on two versions is too much, I think.

Totally agree with you. I tell Boriel to use this switch as FreeBasic does. But It's true that in QBasic this is more important: if you can compile an old app this works in a modern computer. If ZXBC does, the app works on the same machine (or emulator) slightly faster. And as I discussed with Boriel 100% accuracy is imposible because VAL, READ DATA, etc...

When I said 2 compilers I point 2 different parsers for the same compiler.

But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.

I support Boriel 100% with this decision.

I also agree with you and Boriel.

Maybe only as option because most coders use integers only, with rare use of FP. Adding Fixed Point library will blow the code up, and if it is rarely used, it makes no sense to replace all the routines, because if FP is rarely used, the speed does not matter that much, but wasting some of the 41 Kb free memory will kill some projects. This is my opinion.
I already suggested to give the user switch to control which Runtimes the user want to use: "ROM Routines" for slow but small programs or "Custom routines" for fast but larger programs.

Fixed point and Integer shares the implementation. For example when you multiply 2 16bit numbers, the result is a 32bit number. If you use UInteger you choose the lower 16bits of result. If you use smallFixed (doesn't exists, but Fixed in ZXBC is 32bit) you chose the middle 16bits.

The fact that it's rarely used is not a reason for not doing it. At least EXP, LN, and trigonometrical functions are useful not only in 3D. You can do Fourier transforms, differential equations, etc...

Until now the only option for do it in realtime is filling lookup tables with FP Rom routines and interpolate that.

The user needs full control about the 2nd screen. Transparent buffer is maybe good for sprites, but I do not like the idea. If every graphics command will switch the buffers, drawings will apear faster, but for EVERY object! You will see the drawings appear line by line by circle. With present system you can draw complex figures in backbuffer and then switch the screens. If there should be a backbuffer, so I propose following commands:
SetBackbuffer nr,address,mode - Sets the address od a backbuffer (maybe continuous memory as on SAM Coupé, which can address 512 KB, this will be also good for other planed supported plattforms), mode only for other systems where screen modes use different bytes count.
DisplayBuffer nr - Displays a buffer number
UseBuffer nr - Uses Buffer for drawing
SwapBuffer - Swaps tho hardware Buffers (on 128K), changes other Screen to be viewed and Use Buffer to the now invisible screen automaticaly.
Or something similar, but on the other side, nobody stops me to write Subroutines which will do that for me.
Greetings.

See my other post about double buffer, I am agree with "nobody stops me to write Subroutines which will do that for me", of course this will be optional (specified in code or compilation switch)

[sindecencia]

Almost none (if any) of the Speccy games work that way. The Z80 on the Speccy run at 3.5Mhz, and it's almost impossible to redraw the entire screen at 50fps.

It's possible to draw 1 or 2 sprites (but by painting the background with pushes) but yes, it's not useful for a game.

Mostly games just redraw tiny screen portions, and if the got more than 10fps they were considered Ace games. E.g. Alien 8 runs < 10fps for sure (jump over a platform and you will notice it). Remember screen memory is "contended memory" (slower) than ram above 32767 (32K)

Yes, Operation wolf writes every third frame (16.7fps) and it's pure scroll. Cobra writes every second frame (25fps) but mapping is limited (because sprites are literally pushed (with push instructions) from registers. Both games uses a great portion 80%-90% of screen.

The Spectrum 128k allows screen switching with a single out instruction (which can be directly done in ZX BASIC). So I guess the fastest strategy is to predraw both frames and only draw changes in both of them, swiching them with an out. Not sure if any game used this technique, but know there were games which used the alternative screen memory address.

Good idea by redrawing both frames. Commercial games doesn't use that because +2A/+3 were a tiny portion of the market share. But nowdays this has sense. It's the most effective way to avoid flickering. So I think this 3 scenarios are possible:
1. I can redraw the entire screen every 2 or 3 frames. Only page banking is need (an OUT in basic).
2. I only draw parts of the screen (or use sprites without scroll). Page banking with a fast copy of entire/portion (with PUSH/POP) from backbuffer.
3. I draw complex shapes (circles) or some other situation that copying from backbuffer is slower than writes the shape in both buffers.