opcode
12-04-2003, 08:48 PM
My good friend Zaxxon has pointed me a new “creative game machine” being developed, the XGameStation. While the machine itself seems very early in development, there is already a BASIC compiler (called XGS BASIC) available for game programming, though the current version (0.6) is still in a very, very rough stage, almost useless IMHO.
Maybe a few of you already know I am planning an expansion module for the CV, and I found it interesting someone else had a similar idea, including a hobbyist programming language.
Well, while I am busy with several CV games right now, I was thinking about a good game programming language, mostly motivated by the disappointing XGS BASIC. In the first I thought it would be a good idea to develop a programming language around a conceptual machine (the above mentioned expansion), maybe an emulated one. But a little ago I realized it would be interesting to have a good base language developed before the module is even started. So why not create the language around the base CV.
It would prove a very interesting project for several reasons.
1) The CV is a feature rich machine compared to its pre-crash contemporaries.
2) A good game language needs several specific functionalities to allow the programmer to create games with little programming effort.
3) It needs to be very optimized, since the CV has just 1KB of RAM.
So I am thinking about creating a BASIC variation with the characteristics above.
Just as an example, lets think about a macro statement capable of playerfield scroll:
The CV is a tile (or pattern) based machine, meaning it uses 8x8 chars to create a game screen. Since the screen resolution is 256x192 pixels, it means we have 32x24 chars. Doing the math we end with 768 chars. Well, if we create a “frame buffer” to map characters on screen, we would need 768 bytes, which would leave us with just 256 bytes for game variables. So it isn’t a good solution. It is an example of limitation you will find with the CV.
But now think: what if we construct the screen from bigger virtual chars? For example, if we define big chunks of chars as our basic building block, like chunks of 32x4 chars (4 full screen lines). This way we would need just 6 bytes to define the whole screen! Of course I would define smaller chunks if I wish.
So lets do an example code:
Const Chunk1 as chunkline
Const Chunk2 as chunkline
Const Chunk3 as chunkline
Const Chunk4 as chunkline
Const Block1 as chunkblock #or array of chunkline, maybe
Const Block2 as chunkblock
Var PF[12] as playerfield #12 is the number of chunkblocks for this PF
Chunk1 = “34,45,78,56,01,02” #the numbers are character numbers
Chunk2 = “12,90,24,89,02,03”
Chunk3 = “34,89,12,90,00,02”
Chunk4 = “56,90,78,56,00.,09”
Block1 = “chunk1,chunk2”
Block2 = “chunk3,chunk4”
PF = “chunk1,chunk2,chunk1,chunk2,chunk1,chunk2,chunk1, chunk2,chunk1,chunk2,chunk1,chunk2”
# a playerfield var is a circular list
# PF[DISP] will return the current scroll pointer displacement inside a chunkblock, it means, the chunkline inside the chunkblock
# PF[START] will return the starting chunkblock in a playerfield, which will change as "scroll" is used
#PF[SIZE] will return the size of PF list, in this case 12
.....
on interrupt (30) do #it means the scroll will happen every 30 VDP interrupts (twice times every second)
begin
scroll (PF,1,0) #move the whole playerfield 1 char line down
end
#this small example will keep scrolling the screen every half second
Ok, just an example. We can extend it and create many other macros...
Thoughts, suggestions?
Eduardo Mello
Maybe a few of you already know I am planning an expansion module for the CV, and I found it interesting someone else had a similar idea, including a hobbyist programming language.
Well, while I am busy with several CV games right now, I was thinking about a good game programming language, mostly motivated by the disappointing XGS BASIC. In the first I thought it would be a good idea to develop a programming language around a conceptual machine (the above mentioned expansion), maybe an emulated one. But a little ago I realized it would be interesting to have a good base language developed before the module is even started. So why not create the language around the base CV.
It would prove a very interesting project for several reasons.
1) The CV is a feature rich machine compared to its pre-crash contemporaries.
2) A good game language needs several specific functionalities to allow the programmer to create games with little programming effort.
3) It needs to be very optimized, since the CV has just 1KB of RAM.
So I am thinking about creating a BASIC variation with the characteristics above.
Just as an example, lets think about a macro statement capable of playerfield scroll:
The CV is a tile (or pattern) based machine, meaning it uses 8x8 chars to create a game screen. Since the screen resolution is 256x192 pixels, it means we have 32x24 chars. Doing the math we end with 768 chars. Well, if we create a “frame buffer” to map characters on screen, we would need 768 bytes, which would leave us with just 256 bytes for game variables. So it isn’t a good solution. It is an example of limitation you will find with the CV.
But now think: what if we construct the screen from bigger virtual chars? For example, if we define big chunks of chars as our basic building block, like chunks of 32x4 chars (4 full screen lines). This way we would need just 6 bytes to define the whole screen! Of course I would define smaller chunks if I wish.
So lets do an example code:
Const Chunk1 as chunkline
Const Chunk2 as chunkline
Const Chunk3 as chunkline
Const Chunk4 as chunkline
Const Block1 as chunkblock #or array of chunkline, maybe
Const Block2 as chunkblock
Var PF[12] as playerfield #12 is the number of chunkblocks for this PF
Chunk1 = “34,45,78,56,01,02” #the numbers are character numbers
Chunk2 = “12,90,24,89,02,03”
Chunk3 = “34,89,12,90,00,02”
Chunk4 = “56,90,78,56,00.,09”
Block1 = “chunk1,chunk2”
Block2 = “chunk3,chunk4”
PF = “chunk1,chunk2,chunk1,chunk2,chunk1,chunk2,chunk1, chunk2,chunk1,chunk2,chunk1,chunk2”
# a playerfield var is a circular list
# PF[DISP] will return the current scroll pointer displacement inside a chunkblock, it means, the chunkline inside the chunkblock
# PF[START] will return the starting chunkblock in a playerfield, which will change as "scroll" is used
#PF[SIZE] will return the size of PF list, in this case 12
.....
on interrupt (30) do #it means the scroll will happen every 30 VDP interrupts (twice times every second)
begin
scroll (PF,1,0) #move the whole playerfield 1 char line down
end
#this small example will keep scrolling the screen every half second
Ok, just an example. We can extend it and create many other macros...
Thoughts, suggestions?
Eduardo Mello