News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_jjaranda13

8BP

Started by jjaranda13, 10:07, 27 September 16

Previous topic - Next topic

Robert_Lee and 1 Guest are viewing this topic.

jjaranda13

Quote from: sigh on 19:30, 07 January 17
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.




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

Quote from: jjaranda13 on 00:18, 08 January 17
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"  :P [size=78%]based on 8BP library, programmed in 100% locomotive BASIC[/size]
It is a platform style game with horizontal scroll



https://www.youtube.com/watch?v=rhqLdkYjXxU

VincentGR

ME LIKE IT!

Morri

Well done, great looking game.
Your 8BP library is really coming together!
Keeping it Kiwi since 1977

remax

Impressive for a BASIC game !


Would have been a decent commercial game at the time !  :)
Brain Radioactivity

sigh

Has this been compiled?

Good work! Very smooth for basic.

jjaranda13

Quote from: sigh on 10:28, 06 May 17
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 !
TGS is back

Download my productions at:
cpc.scifinet.org

sigh

Quote from: jjaranda13 on 11:03, 06 May 17



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

#36
Quote from: sigh on 17:13, 06 May 17
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

Quote from: jjaranda13 on 21:38, 06 May 17
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  :)
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

sigh

Quote from: jjaranda13 on 21:38, 06 May 17
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

Quote from: sigh on 00:48, 07 May 17
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

Quote from: jjaranda13 on 00:52, 07 May 17

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

Quote from: sigh on 01:27, 07 May 17
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

Quote from: jjaranda13 on 08:14, 07 May 17

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

Quote from: sigh on 11:01, 07 May 17
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

Quote from: jjaranda13 on 13:14, 07 May 17

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

Quote from: sigh on 17:40, 07 May 17
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

Quote from: jjaranda13 on 08:07, 08 May 17
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" :P

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 :)

Powered by SMFPacks Menu Editor Mod