Ccz80 ++ is more and faster with the sprite and the other bases.
Greeting
Very impressive examples. Especially "Nibiru".
I reckon that with the stars in the background, could it work by using palette swaps to make it smoother?
andycadley suggested this idea for the scrolling of the white lines on my football game.
It's bascially having 2 pixels - 1 white and the other black next to each other, then swapping the colours around while you scroll it. It gives a very smooth feeling of scrolling.
Does it compile with FaBaCom, too ?
People could develop and test/debug with normal 8BP/Basic and deliver the final work compiled.
i have tested CPC BASIC Compiler using 8BP
concretely, i have compiled mini-invaders
my conclusions:
- around 50% faster
- difficult to debug (it is machine code)
- no 100% compatible with locomotive basic
- useful for programmers which want more speed or hide their code
Does it compile with FaBaCom, too ?
People could develop and test/debug with normal 8BP/Basic and deliver the final work compiled.
Yes, the problem with fabacom is the RAM usage. A BASIC game that consumes 10KB, after compiling with fabacom takes 20KB. In fact, CPC Basic compiler takes also certain overload. I have compiler nibiru (17KB) and the compiled version takes 22KB (5KB extra).
When there is needed an extra speed...we can :
- eliminate all REM instructions from logic <-- always is a good practice !
- change RSX commands by CALL XXXX <--- less understandable code but faster!
These two recommendations provide an extra speed, and only if you need more speed , the compilation is justified, because takes more RAM and have compatibility problems. For example, in mini-invaders, the sound command doesnt work properly in the compiled version
Channel Status Byte,
Volume Envelope,
Tone Envelope,
Tone Period (1),
Tone Period (2),
Noise Period,
Volume,
Duration of Sound (1),
Duration of Sound (2)channel status,
tone period,
duration,
volume,
volume envelope,
tone envelope,
noise period
I am so impressed by this program.
The ink rotation in your brick example - I'm really interested to see what that would look like if it was compiled, as the differences in speed in your last demonstration was insane! :D . That 50 % increase made an incredible visual difference.
bricks compiled
the bird doest work properly, neither music, but gives you an idea
video .flv is inside zip file
Has this been compiled?
Good work! Very smooth for basic.
not at all. Not compiled. It is interpreted by CPC directly
Again - that's very impressive for it to move at that speed.
As in some of your youtube vids, you've compiled some of your programs to make them move faster, will you compile this one too?
It would be great to see the speed difference. :)
probably not. I have compiled "mini invaders" only for testing purposes. The gain is around 50%. This extra speed is very good for some games. However, if you consider that the program is made in locomotive basic, an increment from 100% to 150% is not so impresive. Normally a compilation should speed up a program around 1000% or even 10000%. The reason is obvious : 8BP has already done the "hard work". sprite printing, scrolling, collision detection, music...is done by 8BP in machine code. The rest of the program is the game logic, which normally is the lightest part of the program. Additionally, if you program BASIC using "massive logics" philosophy (described in 8BP manual) you can obtain a really good performance of that game logic in basic.
In a nutshell: my goal is to provide the best tool to enable programmers to develop games in locomotive basic, interpreted. I want professional quality in BASIC, and this challenge can be reached using 8BP and massive logics.
compilation is a good choice for programmers which want 50% extra speed ( but in that case you also can move to C language) or programmers who want to "hide" their code. In fact 8BP can be used from BASIC, from C, from assembler...whatever you want. 8BP are a bunch of routines accesible at concrete memory addresses , combined with an "structure" of CPC464 memory block assignments (certain area for sprite table, certain area for sprite drawings, certain area for music, etc)
probably not. I have compiled "mini invaders" only for testing purposes. The gain is around 50%. This extra speed is very good for some games. However, if you consider that the program is made in locomotive basic, an increment from 100% to 150% is not so impresive. Normally a compilation should speed up a program around 1000% or even 10000%. The reason is obvious : 8BP has already done the "hard work". sprite printing, scrolling, collision detection, music...is done by 8BP in machine code. The rest of the program is the game logic, which normally is the lightest part of the program. Additionally, if you program BASIC using "massive logics" philosophy (described in 8BP manual) you can obtain a really good performance of that game logic in basic.
In a nutshell: my goal is to provide the best tool to enable programmers to develop games in locomotive basic, interpreted. I want professional quality in BASIC, and this challenge can be reached using 8BP and massive logics.
compilation is a good choice for programmers which want 50% extra speed ( but in that case you also can move to C language) or programmers who want to "hide" their code. In fact 8BP can be used from BASIC, from C, from assembler...whatever you want. 8BP are a bunch of routines accesible at concrete memory addresses , combined with an "structure" of CPC464 memory block assignments (certain area for sprite table, certain area for sprite drawings, certain area for music, etc)
Thank you for your answer.
One more question:
Did you try your ink rotation technique on the bricks? It was extremely impressive on your last demo.
Exactly! The ink rotation is used at the beggining, in the wall made of blue bricks and also in the floor of the first stage "fruity castle"
Yes - I noticed it was used on the blue bricks, but I didn't notice it being used in game? So the red bricks on the ground on the first level, is using the ink rotation method?
yes. Only the ground. The rest of platforms are being moved by CPU, using 8bp scrolling mechanism (command |MAP2SP)
Is there a reason why the blue bricks move much more smoothly than the red bricks in the game?
yes, you are very good observer
blue Bricks at presentation use synchronized sprite printing (|PRINTSP,0,0,1), while during game sprite printing is not synchronized (|PRINTSP,0,0,0). The effect of sync sprites at presentation is that everything is synchronized, including ink rotation command(blue bricks). This provides a smooth scrolling effect.
In my opinion , during game, it is not recommended to use sync sprite printing because although movements are more smooth, the speed becomes lower. Depending of the type of game may be interesting to synchronize or not
So if you were to compile the game, the red bricks bricks would move 50% faster, offsetting the slower speed when using synchronized sprint printing? Would the 50% speed increase be noticeable and worth it?
However synchronization continues being heavy for interpreted BASIC programs. If you compile it, synchronization is the best, even some times too fast, and it is needed for an suitable speed.
That's extremely impressive in regards to the pseudo 3D. Is the pseudo 3D compiled?
:o It's not compiled and it already moves that smoothly and fast! Very nice indeed.
The pseudo-3D is not compiled. All my games and demos run using interpreted Locomotive BASIC. They are BASIC programs using 8BP RSX library, but fully pure interpreted BASIC
new v37 version of the 8BP library available. Faster and with the improved COLAY command. In addition, the manual has been completely revised and the chapter on mass logic improved.(https://pbs.twimg.com/media/EGI2wRFXUAE7V59?format=jpg&name=900x900)
11/12/2019 UPDATE V38 (backward compatible)
I have updated the repository the following changes
library: 8bitsdepoder_v38_001.asm is now included with the following improvements:
command | COLSPALL more powerful. no collision limitations with sprites located in negative coordinates
command | MUSIC: now accepts a new parameter that allows you to choose between playing the music in a loop or once.
command | MUSICOFF: no longer exists, has been replaced by an invocation to MUSIC without parameters
manual: I have updated the manual reflecting the changes in the library and I have included a chapter of first paos at the beginning
Demos: all demos are collected in a menu and are made with v38
games: the game "happy monty" is included
https://github.com/jjaranda13/8BP (https://github.com/jjaranda13/8BP)library:8bitsdepoder_v39_001.asm is now included with the following improvements:command | COLSPALL, id: now scan from collider id + 1command | MUSIC: now accepts a new parameter that allows the sound channel C to be released while the music is playing for use in sound effects with BASIC SOUNDcommand PRINTSPALL : now first print and then animate, so that the first frame of an explosion will be printed. So far when an animation sequence was assigned, the first frame was not printed because it first animated and then printedNow the PRINTSP and PRINTSPALL commands can use images located in any memory area, even outside the space allocated by the 8BP library for sprites.Fixed a minibug detected in a specific case of overwriting manual:I have updated the manual reflecting the changes in the libraryDemos: all demos are collected in a menu and made with v39. now there is a new demo to try music and FX at the same time
I guess the BASIC interpreter overhead is a real killer even with fast RSXs!The speed is amazing when they are compiled:
Just need a decent BASIC compiler that can support RSXs now... or just use C.
I guess the BASIC interpreter overhead is a real killer even with fast RSXs!
Just need a decent BASIC compiler that can support RSXs now... or just use C.
Por último, a los que deseáis programar con 8BP en C, os diré que el wrapper de C ( un 8bp.h) lo tengo a medias y funciona perfectamente, de modo que podréis disfrutar de esta capacidad en la próxima versión V40
Will there be a decent english translation soon ? love to get into 8bp but google translation is a bit ..... weird :o :P
Since I'm not into C I will only use the Basic Part ....
Anyway awesome work when I look at the demos 8) 8) 8)
No it isn´t ... I´m on Mac here ;)
The alternative here for you would be CPC BASIC 3.
8BP's function is for coding action games...Since I allready did some google translations ... yes it is but you can code a lot of other things with it ;D
I wasn't aware of CPC BASIC 3.
The problem with CPC BASIC 3 is that:
- CPC BASIC 3 uses 5KB extra (apart from your program) for your code
- additionally ,CPC BASIC 3 uses 16KB extra for work area
in total, a program of 5KB is converted into a 26 KB !!!! This is the reason why i don't recommend the use of BASIC 3
8BP uses only 8KB . And the news: in 8BP v40 you can mix BASIC and C only consuming 2KB extra, including all 8BP commands which are available now in C and a reduced set of BASIC commands available from C (such as INKEY, PRINT, LOCATE, PLOT, DRAW ,SOUND etc). These 2KB includes all 8BP and this mini BASIC. Your programs have 22 KB free for your code + 8.5 KB for graphics + 1.4 KB for music. You can develop a game in BASIC and when it is finished translate directly (very very easy) the "game cycle" (only the game cycle) into C , compile it and obtain a great & fast professional game. This game is a mix between LOCOMOTIVE BASIC and C (only for game cycle)
in 8BP v40 if you want to use only BASIC, you continue having 24 KB free for your BASIC code, like in V39
I was looking for the draft version of the documentation but I can't find it. It says in the ZIP, but where can I find this?
I would love to try this for my next game but my Spanish is too bad to understand the docs.
Hi good afternoon.
the inventions for the cpc don't stop there.
thank you.
i have a cpc6128.
how can you use your programs if i want to have the range 0x4000 to 0x7fff myself?
So if the sdcc programs start at 0x8000?
does your basic also work with 0x8000?
greeting
thank you.
I don't want to influence the program in a very complicated way.
that should be built by the inventor in such a way that only the start address has to be entered differently than is usual with other programs: sdcc, ccz80 ++, cpctelera etc.
hello, good job.
i would like more extensions for c and some interesting examples to learn with c.
spagetticocde in this way should go away.
another type of programming without lines in basic
---------------------------
340 l=0:naut[l*6+0]=100:naut[l*6+1]=160:naut[l*6+2]=220:naut[l*6+3]=-60:naut[l*6+4]=-90:naut[l*6+5]=-40:'level 0
350 l=1:naut[l*6+0]=400:naut[l*6+1]=200:naut[l*6+2]=300:naut[l*6+3]=250:naut[l*6+4]=-300:naut[l*6+5]=-300:'level 1
351 l=2:naut[l*6+0]=400:naut[l*6+1]=200:naut[l*6+2]=300:naut[l*6+3]=-400:naut[l*6+4]=0:naut[l*6+5]=-100:'level 2
352 l=3:naut[l*6+0]=400:naut[l*6+1]=400:naut[l*6+2]=50:naut[l*6+3]=50:naut[l*6+4]=-200:naut[l*6+5]=-200:'level 3
353 l=4:naut[l*6+0]=400:naut[l*6+1]=200:naut[l*6+2]=50:naut[l*6+3]=-300:naut[l*6+4]=-200:naut[l*6+5]=-400:'level 4
355 l=5:naut[l*6+0]=-500:naut[l*6+1]=-500:naut[l*6+2]=550:naut[l*6+3]=0:naut[l*6+4]=-300:naut[l*6+5]=550:'level 5
--------------------------
greeting
hello,
echo "* LOAD "ciclo.bin", 20000 *"
LOAD "ciclo.bin",20000
is error.
how big(byte) can a C-program be from sdcc for 8bp?
thanks.
cpc basic 3 uses this ccz80 to compile. there is the successor ccz80 ++ if you use the cpc basic3, you can also familiarize yourself with the ccz80.it's not difficult.
greeting
you can enlarge this ciclo.c as you like, eg up to 10k compiled code?
greeting
the sprite are not transparent, but rather square blocks are visible.
Is there a current version of the documentation in English?