New Kai Magazine Game

Page 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8

By AxelStone

Prophet (3189)

AxelStone's picture

18-08-2015, 22:32

Question: why is this thread drifting to a ASM vs Turbo Pascal thread? The purpose of this thread is to discuss about the new MSX game, not about the tools / language used. I think that every developer must use the tools where he feels confortable and it's stupid try to persuade him to use another one.

Kai is a good Basic programer, so best results for this game will be in Basic, no matter what advantages can assume ASM respect Turbo Basic.

A new game for MSX is being developed, and it seems it has a very hard work. It's simply a very good new.

By Kai Magazine

Paragon (1420)

Kai Magazine's picture

18-08-2015, 22:34

Manuel wrote:

Kai - Have fun creating stuff! I'm looking very much forward to the results Smile Especially if it's for MSX! It's great to see you try new things.

Thank you Manuel!

It is my personal goal that, any game I create in the future, for whatever system, it will have its MSX version, even if I do not earn any money with the MSX version.

This is my commitment to the MSX system, which gave me the best years of my childhood/adolescence (until I started going out with girls Tongue )

By Manuel

Ascended (19209)

Manuel's picture

18-08-2015, 22:49

AxelStone wrote:

Question: why is this thread drifting to a ASM vs Turbo Pascal thread?

Huh? Who mentioned Pascal??

By AxelStone

Prophet (3189)

AxelStone's picture

18-08-2015, 22:56

Sorry, ASM vs Turbo Basic Tongue

By JohnHassink

Ambassador (5645)

JohnHassink's picture

18-08-2015, 22:59

Kai Magazine wrote:

Turbo basic is NOT a bad tool if you REALLY know how to use it.

By the way, if you write "defint a-z" just after the Call turbo on command, the whole program will work MUCH faster because integer variables are handled correctly. Just one of MANY tricks I know, thanks to years and years of practice with turbo basic.

I love Turbo BASIC, and it can indeed be very powerful. You proved that especially with No Name.
Could you please one day write a little tutorial or list with some more of those tricks? We could also include it in the MSX Wiki here on MRC.
One thing though: one big disadvantage I almost always run into with Turbo BASIC (I use NestorBASIC specifically by the way), is that the RAM for programs seems to be full so fast. Even if I store things like map data and variables in VRAM.

By flyguille

Prophet (3028)

flyguille's picture

19-08-2015, 00:32

JohnHassink wrote:
Kai Magazine wrote:

Turbo basic is NOT a bad tool if you REALLY know how to use it.

By the way, if you write "defint a-z" just after the Call turbo on command, the whole program will work MUCH faster because integer variables are handled correctly. Just one of MANY tricks I know, thanks to years and years of practice with turbo basic.

I love Turbo BASIC, and it can indeed be very powerful. You proved that especially with No Name.
Could you please one day write a little tutorial or list with some more of those tricks? We could also include it in the MSX Wiki here on MRC.
One thing though: one big disadvantage I almost always run into with Turbo BASIC (I use NestorBASIC specifically by the way), is that the RAM for programs seems to be full so fast. Even if I store things like map data and variables in VRAM.

because it shares the main disavantage of the Basic interpreter, that is the work area limited to the bottom 32k.

By Kai Magazine

Paragon (1420)

Kai Magazine's picture

19-08-2015, 00:38

JohnHassink wrote:
Kai Magazine wrote:

Turbo basic is NOT a bad tool if you REALLY know how to use it.

By the way, if you write "defint a-z" just after the Call turbo on command, the whole program will work MUCH faster because integer variables are handled correctly. Just one of MANY tricks I know, thanks to years and years of practice with turbo basic.

I love Turbo BASIC, and it can indeed be very powerful. You proved that especially with No Name.
Could you please one day write a little tutorial or list with some more of those tricks? We could also include it in the MSX Wiki here on MRC.
One thing though: one big disadvantage I almost always run into with Turbo BASIC (I use NestorBASIC specifically by the way), is that the RAM for programs seems to be full so fast. Even if I store things like map data and variables in VRAM.

Hello JohnHassink, I would be honored to share with you any tricks and techniques I know about Turbo basic, I am a big fan of you, and I admire you.
Time permitting, I will write a tutorial of tricks and techniques to optimize the usage of Turbo Basic in all areas of developement.
Last year I shared many of this tricks in the spanish MSX.ORG forum, trying to impulse new indie developement on the MSX with Turbo basic, and several people started a few projects, AxlStone being one of them.
If this year I have some spare time, I will do this tutorial.
For now, I can tell you that, while NestorBASIC is an EXELENT tool which allows you easy access to many features, it is not the best for turbo basic game developement, because it takes away some of the "work area" memory, causing to run out of memory quicker.
None of my games work on NestorBasic, because NestorBasic does not let enough free memory.
Also, NestorBasic requieres 128k of memory to work, making your games or programs incompatible with 64k MSX2 or 2+ (wx, wsx). Considering that each year there are less european MSX2 because there is no new production, and there are more imported japanese msx with 64k of ram, it is beginning to be a problem.
Nuts and No Name only requiere 64k to work, making them compatible with any msx2 computer.
Also, by pressing CTRL or using some POKES to create the same effect, you can free 1,5K of work memory by disabling unnecessary drivers.
anyway, you will always run out of memory when creating a big game engine with turbo basic.
The trick is to create many similar engines, and alternate them.
For example; some stages on NUTS have boxes and knives, but you cannot climb or fall.
Other stages have this climbing or falling features, but no items.
In No Name, some stages have Parallax effect, but the map is linear, and other areas have a huge laberinthic map, but no parallax effect.
It is by alternating different engines that I create a game with many features, with so little memory.
Also, by putting as many commands as you can in a single line (whenever is possible), instead of using a line for each command, saves memory. This, applied to the whole list, ends up in a considerable amount of memory saved.

Regarding mathematical speed;
Using the defint a-z just after the call turbo on defines all variables as integers, but you can still define other variables afterwards. But if you try to work with integers as much as possible, with the Defint A-Z function you will gain A LOT of speed.
try this:
10 _turbo on
20 for i = 0 to 20000
30 next i
40 _turbooff

Calculate how long it takes.
repeat this loop 10 or 20 times by adding another for x=0to20, for example, and calculate the time.
Now add the defint a-z:
10 _turbo on
15 defint a-z
20 for i = 0 to 20000
30 next i
40 _turbooff

do the same tests as you did before, and see how much faster the test works. You will not belive it.

So try to use integers as much as you can.

Regarding graphic performance in turbo basic:

Turbo basic has 2 ways to handle graphic copys on Screen 5, a really fast one, ASM speed, and a very slow one, basic speed.

When you copy a graphic you define a square; x, y, xlenght, ylength

if the X is an EVEN number (0, 2, 4, 6, 254...) and the Xlength is an ODD number (1,3,5,7,255...) the copy will be really fast. Really really fast.

Try this:

5 screen 5: set page,1: bload"fullscreengraphic.sc5",s
10 _turbo on
15 defint a-z
20 for i = 0 to 254 step 2
25 copy (i,0)-(254,211),1 to (0,0),0
30 next i
40 _turbooff

This is the slow mode because both x and xlength are EVEN numbers (0,254) breaking the rule for the turbo copy, and it will go at basic speed.

Now try this:
5 screen 5: set page,1: bload"fullscreengraphic.sc5",s
10 _turbo on
15 defint a-z
20 for i = 0 to 254 step 2
25 copy (i,0)-(255,211),1 to (0,0),0
30 next i
40 _turbooff

now the x will be always an EVEN number, and the Xlength will be an ODD number (255), thus following the rule of the fast copy.

You will see the speed is MANY times faster, and exactly as fast as in ASM.

By using this simple basic rules, you can create code at almost ASM speed with turbo basic.

There are many more tricks, but it is 00:37 AM here and I am going to sleep. It is enough for today.

Regards!

By flyguille

Prophet (3028)

flyguille's picture

19-08-2015, 02:09

Kai Magazine wrote:
JohnHassink wrote:
Kai Magazine wrote:

Turbo basic is NOT a bad tool if you REALLY know how to use it.

By the way, if you write "defint a-z" just after the Call turbo on command, the whole program will work MUCH faster because integer variables are handled correctly. Just one of MANY tricks I know, thanks to years and years of practice with turbo basic.

I love Turbo BASIC, and it can indeed be very powerful. You proved that especially with No Name.
Could you please one day write a little tutorial or list with some more of those tricks? We could also include it in the MSX Wiki here on MRC.
One thing though: one big disadvantage I almost always run into with Turbo BASIC (I use NestorBASIC specifically by the way), is that the RAM for programs seems to be full so fast. Even if I store things like map data and variables in VRAM.

Hello JohnHassink, I would be honored to share with you any tricks and techniques I know about Turbo basic, I am a big fan of you, and I admire you.
Time permitting, I will write a tutorial of tricks and techniques to optimize the usage of Turbo Basic in all areas of developement.
Last year I shared many of this tricks in the spanish MSX.ORG forum, trying to impulse new indie developement on the MSX with Turbo basic, and several people started a few projects, AxlStone being one of them.
If this year I have some spare time, I will do this tutorial.
For now, I can tell you that, while NestorBASIC is an EXELENT tool which allows you easy access to many features, it is not the best for turbo basic game developement, because it takes away some of the "work area" memory, causing to run out of memory quicker.
None of my games work on NestorBasic, because NestorBasic does not let enough free memory.
Also, NestorBasic requieres 128k of memory to work, making your games or programs incompatible with 64k MSX2 or 2+ (wx, wsx). Considering that each year there are less european MSX2 because there is no new production, and there are more imported japanese msx with 64k of ram, it is beginning to be a problem.
Nuts and No Name only requiere 64k to work, making them compatible with any msx2 computer.
Also, by pressing CTRL or using some POKES to create the same effect, you can free 1,5K of work memory by disabling unnecessary drivers.
anyway, you will always run out of memory when creating a big game engine with turbo basic.
The trick is to create many similar engines, and alternate them.
For example; some stages on NUTS have boxes and knives, but you cannot climb or fall.
Other stages have this climbing or falling features, but no items.
In No Name, some stages have Parallax effect, but the map is linear, and other areas have a huge laberinthic map, but no parallax effect.
It is by alternating different engines that I create a game with many features, with so little memory.
Also, by putting as many commands as you can in a single line (whenever is possible), instead of using a line for each command, saves memory. This, applied to the whole list, ends up in a considerable amount of memory saved.

Regarding mathematical speed;
Using the defint a-z just after the call turbo on defines all variables as integers, but you can still define other variables afterwards. But if you try to work with integers as much as possible, with the Defint A-Z function you will gain A LOT of speed.
try this:
10 _turbo on
20 for i = 0 to 20000
30 next i
40 _turbooff

Calculate how long it takes.
repeat this loop 10 or 20 times by adding another for x=0to20, for example, and calculate the time.
Now add the defint a-z:
10 _turbo on
15 defint a-z
20 for i = 0 to 20000
30 next i
40 _turbooff

do the same tests as you did before, and see how much faster the test works. You will not belive it.

So try to use integers as much as you can.

Regarding graphic performance in turbo basic:

Turbo basic has 2 ways to handle graphic copys on Screen 5, a really fast one, ASM speed, and a very slow one, basic speed.

When you copy a graphic you define a square; x, y, xlenght, ylength

if the X is an EVEN number (0, 2, 4, 6, 254...) and the Xlength is an ODD number (1,3,5,7,255...) the copy will be really fast. Really really fast.

Try this:

5 screen 5: set page,1: bload"fullscreengraphic.sc5",s
10 _turbo on
15 defint a-z
20 for i = 0 to 254 step 2
25 copy (i,0)-(254,211),1 to (0,0),0
30 next i
40 _turbooff

This is the slow mode because both x and xlength are EVEN numbers (0,254) breaking the rule for the turbo copy, and it will go at basic speed.

Now try this:
5 screen 5: set page,1: bload"fullscreengraphic.sc5",s
10 _turbo on
15 defint a-z
20 for i = 0 to 254 step 2
25 copy (i,0)-(255,211),1 to (0,0),0
30 next i
40 _turbooff

now the x will be always an EVEN number, and the Xlength will be an ODD number (255), thus following the rule of the fast copy.

You will see the speed is MANY times faster, and exactly as fast as in ASM.

By using this simple basic rules, you can create code at almost ASM speed with turbo basic.

There are many more tricks, but it is 00:37 AM here and I am going to sleep. It is enough for today.

Regards!

just a little correction, that copy instruction, don't accept X and Xlenght, it accept X_start and X_end for area to copy, the same for the Y coordinate.

So I assume, that (0,0)-(255,211), mean that it go from 0 to 255 pixels = 256 pixels per lines (an even length), and from 0 to 211 (212 lines), so even again. In that case, if talking about Screen 5, the copy instruction can issue a BYTE COPY, instead a LOGICAL COPY. But this will only if not LOGICAL operation is set (like color XOR NOT AND OR ....). And IIRC, it is not about MANY TIMES FASTER, it is just twice faster because copying BYTES instead of working with nibbles.

By anonymous

incognito ergo sum (116)

anonymous's picture

19-08-2015, 04:09

You still haven't addressed some of my concerns:

- Why aren't the iOS, OS X and Android versions not being released with the lowest funding goal, since those just require a minimal license fee ($25-100), don't have to go through a strict approval process, and generating the binaries implies just clicking a few buttons in Unity?

- How were you planning to pass the approval processes for PlayStation, Xbox or Nintendo distribution?

You also keep saying that I'm posting inacurate statements. Please point which ones these are, and explain what's inacurate about them.

Kai Magazine wrote:

Hello flyguille, no matter how technical you get, the truth is that, an engine based on 90% graphics cost, the programming language will make very little difference.
If 90% of the work is being made by the VDP, it will make little to no difference (performance wise) if it is made on ASM or Turbo basic, because even if ASM can be 10 or 20 % faster (only at times, depending on which kind of program you are developing, this 10 or 20 % means an increase of a 1 or 2 % of a program that is based 10% on z80 and 90% on VDP.

Where did you pull these numbers from? How did you benchmark this 1-2% performance increase for an assembler program VS the same program written in BASIC? I do not believe these numbers are at all accurate.

Kai Magazine wrote:

To create a big game on ASM is just not practical. It takes too long, and time (the last 20 years) has proven to be impossible.

Not really. Other people are doing it. Anyway, this isn't a thread on programming in assembler VS BASIC. I don't really care what language people code on because after all, we're still here because we're having fun with our machines.

Kai Magazine wrote:

It is, as if today you want to create a PC game on ASM; The ASM is still much faster than any existing gaming engine, but noone would be stupid enough to start a big PC game on ASM, having tools that allow you to develope hundreds of times faster, and the speed loss is just insignificant.

Not true. On a modern platform you program in C (C++/C#/Objective-C/whatever) because of several reasons:

- Modern processors are very complex: out-of-order execution, instruction alignment, multithreading, cache coherence, etc. Modern compilers take care of most of this complexity.

- Modern compilers can optimize code better than most programmers.

- In modern systems you don't code against the bare metal. You use huge APIs and libraries provided by the vendor, and these libraries are written in C.

Kai Magazine wrote:

We must use the best tools we have to acomodate the little resources we have, to create as much contents as fast as we can, with the little time we have. Turbo basic just does the job for me.

That's all fine with me. As I said, I don't really care what language you choose to code in. My concerns are about the unrealistic goals set in your KickStarter campaign.

Kai Magazine wrote:

I belive Turbo basic is nowadays the best (if not the only) way to develope good big games on MSX, due to its advantadges (fast coding, fast results) even if it is a bit slower than ASM.

I strongly disagree with this statement.

By AxelStone

Prophet (3189)

AxelStone's picture

19-08-2015, 07:49

flyguille wrote:

because it shares the main disavantage of the Basic interpreter, that is the work area limited to the bottom 32k.

Sadly is the worst disavantage of Turbo Basic: the main program it's limited to 23kb shared by interpreted code (Basic) and compiled code (Turbo Basic), so your main program in Basic could not exceed about 10-11Kb in order to leave enought space to compiled code. 23Kb is too short Crying

Page 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8