8BP

[jjaranda13]

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! . That 50 % increase made an incredible visual difference.

Hi Sigh
You are right!!! the visual difference is really good. When I say that 50% is not too much is because i compare the usual ratios between BASIC and compiled , but this case is special because invocations to 8BP make a lot of work in machine code


i am working in a scrolling game with platforms made of bricks. my initial tests works fine, i move 5 big platforms very fast across the screen using |RINK, and a special animation sequence based on different inks. The result is amazing and i will upload a video very soon

[jjaranda13]

bricks compiled


the bird doest work properly, neither music, but gives you an idea


video .flv is inside zip file

[sigh]

bricks compiled


the bird doest work properly, neither music, but gives you an idea


video .flv is inside zip file

The forward motion looks so smooth especially with the background graphic of the house and tree! That's really impressive and a great demonstration.
When he moves in the opposite direction, the tiles start to speed up and has a strange strobing effect? What is making the tile do that? Is there anyway to stop it from happening?

Nevertheless, the speed and smoothness makes it outstanding for a demo created in Basic.

[jjaranda13]

hi guys


new game "fresh fruits & vegetables"  [size=78%]based on 8BP library, programmed in 100% locomotive BASIC[/size]
It is a platform style game with horizontal scroll

[VincentGR]

ME LIKE IT!

[Morri]

Well done, great looking game.
Your 8BP library is really coming together!

[remax]

Impressive for a BASIC game !


Would have been a decent commercial game at the time ! 

[sigh]

Has this been compiled?

Good work! Very smooth for basic.

[jjaranda13]

Has this been compiled?

Good work! Very smooth for basic.

not at all. Not compiled. It is interpreted by CPC directly

[Shining]

Wonderful ! Thank you !

[sigh]

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.

[jjaranda13]

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)

[AMSDOS]

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)

I can only assume that perhaps with you posting pictures of your new game in this thread in the programming section, people are assuming you're going to work on it further. Usually what people do is announce the new game in the Games or News Section 

[sigh]

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.

[jjaranda13]

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"

[sigh]

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?

[jjaranda13]

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)

[tjohnson]

I was playing platoon which has horizontal scrolling but it looks quite chunky, definitely not single pixel scrolling more like 2 or 4 pixels by the looks of it.  I guess it will just be some sort of software scroll.  Can anyone tell?

[sigh]

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?

[jjaranda13]

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

[sigh]

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?

[jjaranda13]

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?

Extact! if you compile the game then the best is to use synchronous sprite printing during the game. The slower speed of sync is compensated by the game logic compilation and the result is quite good. I have tested it some time ago with "mutante montoya". When i created this game, at the beggining was very very slow. Then I compiled it and it was too fast. Then I sync it and result was perfect.
After This experience i began to create "massive logics" technic to program games in basic. Now, 8BP is faster and if you combine massive logics with 8BP the result is quite good. 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.

[sigh]

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.

Awww man! Now I really want to see a compiled version of "Fresh fruit and Vegetables"

[jjaranda13]

News from 8BP!


available new game "3D racing one" a pseudo 3D racing game based on 8BP v32
https://www.youtube.com/watch?v=vwiPe--Z6RA&feature=youtu.be

[Gryzor]

This looks cute and wonderfully retro