I haven’t done much 3D programming in Blitz3D. You can achieve quite a lot with a small effort with it. Also in Monkey2 programming language is the main functionality of Blitz3D. The idea to program a starfield cube came from an Amiga remix tune, that has speech in it: ”Starfield in a box. OMG it is rotating!” Back in the time it was hard to program things like that in assembly on Amiga. Nowadays even I can put a code together, that does the job in Blitz3D.
Starfield cube 2:
Making the starfield cube 2 program made me to create also the following video as a result of inspiration with Blitz3D:
The tiger in the cube (in some parts of the video) is from a photo of my trip to Zoo of Helsinki (Korkeasaaren eläintarha). The tiger seemed to be a bit stressed while people were watching it. Though, I remember someone saying it’s smart, because it uses the same always the same paths, when walking.
I seem to live in the past… Monkey X programming language has evolved into Monkey2, but I’m still sometimes using Monkey X.
I made an example class to use in Monkey X with bitmap fonts converted with my Font 2 PNG. The example uses old Mojo-module, but old examples on scaling bitmap font made with Font 2 PNG will give you an idea of an alternative way to implementing this.
Next, let’s take a look at a screenshot:
Next to the code:
Class MyApp Extends App
' Font 1
font1 = New MyFont
font1.gfxFont = LoadImage("font1.png")
font1.fontDat = allocateArray(95,2)
font1.scale = 1
font1.maxHeight = 71
file = FileStream.Open("monkey://data/font1.dat","r")
For Local i:Int = 0 To 95 - 1
font1.fontDat[i] = file.ReadInt()
font1.fontDat[i] = file.ReadInt()
' Font 2
font2 = New MyFont
font2.gfxFont = LoadImage("font2.png")
font2.fontDat = allocateArray(95,2)
font2.scale = 1
font2.maxHeight = 43
file = FileStream.Open("monkey://data/font2.dat","r")
For Local i:Int = 0 To 95 - 1
font2.fontDat[i] = file.ReadInt()
font2.fontDat[i] = file.ReadInt()
gfxBG = LoadImage("bg.jpg")
drawString(font1, "Testing font 1", 10, 10)
drawString(font2, "Testing font 2", (640 - (stringWidth(font2, "Testing font 2") * font2.scale)) / 2, (480 - (font2.maxHeight * font2.scale)) / 2)
Function drawString(font:MyFont, text:String, x:Float, y:Float)
Local len = text.Length()
chrs = text.ToChars()
For Local i = 0 To len - 1
' pos. in font.png width in pixels in font.png
DrawImageRect font.gfxFont, x, y, font.fontDat[chrs[i]-32], 0, font.fontDat[chrs[i]-32], font.maxHeight, 0 , font.scale, font.scale,0
x = x + font.fontDat[chrs[i]-32] * font.scale
Function stringWidth:Int(font:MyFont, text:String)
Local len:Int = text.Length()
Local length:Int = 0
chrs = text.ToChars()
For Local i:Int = 0 To len - 1
length = length + font.fontDat[chrs[i]-32]
Function allocateArray:Int(i:Int, j:Int)
Local arr:Int = New Int[i]
For Local index = 0 Until i
arr[index] = New Int[j]
Font 2 PNG prints the max height of the font after converting. The value is in practice just the height of the png-file.
As a reminder: Font 2 PNG produces two files, font.png and font.dat for one font. The font.dat-file holds the information for each character with two 4 byte integers, first tells the position in pixels in font, the second the width of the chatacter in pixels.
I hope this example gives you some ideas on how to use different fonts converted with Font 2 PNG.
Feel free to use the code above.
PS. I also made new version of part 1 of my Old School series demonstration in Monkey X. Video below:
From the source code in the video you’ll get an idea, how this font class could be used with Mojo2-module.
This morning I made new Old School demonstration in Monkey X. This is now 9th in the series.
Not much is changed in the code from the previous Old School demonstration. What actually required some work, was the font. As in all my Old School demonstrations, I used my Font 2 PNG program. With Mojo2-module one can use for one picture the following: “pic.png”, “pic_n.png” and “pic_s.png”. The programmer doesn’t need to worry about “_n” and “_s” versions of an image, Mojo2 takes care of them. I’ve written all I know from those extra pictures in the first old school post. I may make a better version of it in code-wise and perhaps add some extra too…
Anyway in this 9th version there are 3 versions of each character that are individual png-files.
See the magic: 🙂
I may share the Monkey X source code for these later Old School demonstrations later.
I made today a little Monkey X Pro demonstration: Rolling and rotating scrolltext (Old School VIII). Now it works perfectly. Like in Old School VII, the letters fade in and out at the bottom of the circle of letters. I have used my Font 2 PNG program to grab individual characters of a ttf-font to png-images for the program. Perhaps I will later share the source code of the demonstration…
Enjoy the nostalgia! 🙂
The idea behind the code of the rolling and rotating scrolltext:
At every update frame 30 characters (png-images) from the scrolltext are drawn in a form of a circle, each character with 12 degrees step (12 *30 = 360), let angle related to this angle be angle1
When drawing the character images, the angle that increases in 12 steps is added to each character in addition to this angle is added other angle variable, let this be angle2, that is decreased (the direction of rolling and rotating) by 1 degrees at every update frame
Because of my (probably clumsy but working 🙂 )implementation:
If angle2 Mod 12 = 0 Then
angle2 = angle2 + 12
scrollTextOffset = scrollTextOffset + 1
in DrawImage method rotation angle is angle1 + angle2 + constant that adjusts the letters to the right place on the circle
As to he fade out and fade in for the letter images, you may adjust the letters with alpha values as you best you see it is sensible, probably somewhere at the bottom of the circle.
That’s it! Do try to make make your own version with programming language of your choice. I recommend my Font 2 PNG program for the font.
The first time I saw this kind of effect created was some time in the late 80s on Amiga in following demo:
Ah! Those good old Amiga demos. Kind of magic at their time.
I recently made version 2 from my poor Old School VI video. Today I got finished Old School VII video. Both demonstrations are programmed in Monkey X Pro. VII has that nice demo scene style synth music like Old School V. 🙂
In the Old School VII the the new letters fade in to the screen as the scroll text goes on and when the letters have gone the whole circle, they fade out…
My first Amiga was Commodore Amiga 500 with Kickstart 1.3 plus TV-modulator in order to get the picture to TV. The contents on the TV were hardly readable as it comes to any text. For playing games quality of graphics output was decent.
Later I got SCART cable to connect the graphics output of Amiga to TV. That was something else, one could even read the text on the TV without getting red eyes and tears. 🙂 A bit later I finally got a 14” monitor to use with Amiga SCART cable as the connect cable for graphics and sound output.
It was 1988 when SoundTracker 2.5 was released, which was the first SoundTracker that didn’t crash on Amigas with Kickstart 1.3. I don’t have any real education on making music. The way I have learned making music was listening to ”real” music and music modules other people had composed with Amiga. As I got my Amiga 500’s audio output connected to an old Pioneer amplifier with big speakers it was simply amazing to listen to Amiga’s music that was built with 8-bit samples.
Working with an Amiga 500 with only 512kb of (CHIP) RAM was quite a limitation. Usually I didn’t use Workbench (Amiga’s graphical user interface) but AmigaDos as operating system environment when programming with Amiga. This was because Workbench of course took some of the limited amount of memory available for the user.
Here’s a video from one unfinished Amiga project I was working 2003 – 2004 (not from my early Amiga times, though 🙂 ):
You may be interested int the source code of the demonstration above.
With only one disc drive (with Amiga 500 I didn’t ever have a hard disk) all the AmigaDos commands were read from directory named ”c” – c for command. For the sake of speed (disc drives are slow) it was possible to put the most used AmigaDos commands to RAM disc or make them “permanent” to RAM memory. I don’t remember the AmigaDos command to do this, but this was faster than reading from the RAM disc anyway… Putting AmigaDos commands to RAM of course also decreased the amount of available memory for example for a text editor and testing the compiled and linked assembly program…
Later, when I bought an additional disc drive, Senator, to my Amiga 500 working got easier: It wasn’t only the question of available memory, but also the available space on a single disc. Full capacity of Amiga’s DD disc is 880kb, the space available after formatting the disc was of course a little less.
When working with the additional disc drive, I made boot disc of my own to start the system, where I had put all the needed AmigaDos commands, libraries, applications and so on. My own work was on the additional disc drive. Ah, how things got easier…
The description above compared to working with desktop systems nowadays may be a bit amusing to younger generations… 🙂
It’s night when I’m writing this. I came up with a little Monkey X tutorial on how to program the bouncing of the ball, when it touches the bat in the “old school way” — like in the popular C64 game Krakout in the 80s.
In the video for the tutorial you can see, that as the ball touches the bat for the first time, delta y doesn’t change. This is because both the ball and the bat are uneven as height in pixels; now both the ball and the bat have a middle point.
This is just a short piece of code, that doesn’t handle the case, when the ball is at the horizontal top or bottom of the bat. There’s some extra work for anyone who wants to make an 80s style Krakout game. 🙂
The delta y for the ball is calculated simply how the ball’s y-position is related to the middle point to the bat. The “scale” variable is used to adjust the max y-speed of the ball.
Source code below:
Class MyApp Extends App
Field gfxBG:Image, gfxBat:Image, gfxBall:Image
Field scaleX:Float, scaleY:Float
Field touchX:Float, touchY:Float
Field prevTX:Float, prevTY:Float
Field ballX:Float, ballY:Float
Field ballDX:Float, ballDY:Float
' Load graphics
gfxBG = LoadImage("bg2.png")
gfxBat = LoadImage("bat3.png")
gfxBall = LoadImage("ball4.png")
scaleX = DeviceWidth() / 640.0
scaleY = DeviceHeight() / 480.0
ballX = 42
batY = 230
ballY = 230 + 36 - 8
ballDX = 2
ballDY = 0
prevTY = 0
touchY = 0
touchX = 0
touchY = 0
scale = 16
' The if-sentence prevents the bat to appear at bottom of the screen at the start..
If prevTY <> 0 Then batY = batY - (prevTY - touchY)
prevTY = touchY
touchY = TouchY()
touchY = touchY / scaleY
' Keep the bat in the borders of the screen
If batY < 0 Then batY = 0
If batY > 479 - 72 Then batY = 479 - 72
' Move the ball
ballX = ballX + ballDX
ballY = ballY + ballDY
' Keep the ball in the borders of the screen
If ballY < Abs(ballDY) Then ballDY = -ballDY
If ballY > 479 - 17 Then ballDY = -ballDY
If ballX < -Abs(ballDX) Then ballDX = -ballDX
If ballX > 639 - Abs(ballDX) - 16 Then ballDX = -ballDX
' Calculate the deltaY value for the ball in the "old school way"...
If ballX >= 601 - 16 And ballY + 16 > batY And ballY < batY + 72 Then
ballDY = -((batY + 36) - (ballY + 8)) / scale
ballDX = -ballDX
DrawImage gfxBall, ballX, ballY
DrawImage gfxBat, 601, batY
Feel free to use and improve the source above in your own projects.
Here’s the graphics to download (license: public domain), except the background picture (right click and save as…):
The bat is 32 x 73 pixels as size, the ball is 16 x 17 pixels.
For comparing to the C64’s popular Krakout, see the video below:
Many years ago I started to program Krakout style game in the spirit of the good old Commodore 64, but as usual, something went wrong. Three months work with multiple levels and a level editor programmed in Blitz3D were lost because I hadn’t taken backups of the files, when I, well, “fixed” the Windows installation I had at the time…
My first Commodore Amiga was Amiga 500, which I got eventually upgraded with additional disc drive and 2 MB of (real) FAST memory.
Although I was more into programming, demo scene demos and making music with Amiga than playing games in my Amiga times, I had some fine moments with games too.
One of the first — if not the first — game that I saw on Amiga was Hybris in 1987 at my friend’s place, while I was still using my good old Commodore 64. Seeing Hybris on Amiga was quite a blast for me: I thought it was graphically and musically at the same level than coin up games I’ve seen as a kid.
Take a look and be amazed: 🙂
I remember, that I always wondered (and still do), how the programmers had the time and skill to program this kind of quality game in those early years of Amiga games. All those attack waves, complicated movements of enemy ships, so many bobs (blitter objects) in addition to sprite usage, all movement in one 50hz frame, though smooth scrolling was made every second frame. One thing that probably helped to make this game possible was the use of only 256 pixels as width of the screen; this allowed the programmer(s) to use assembly instruction lsl instead of mulu when calculating the position of an object to the screen. Assembly instruction mulu is much slower than lsl, which shifts the bits to the left making multiplications needed somewhat fast.
Some time at my high school (lukio) times I programmed a program that took an IFF image as input and as output the program produced a binary file that consisted of coordinates to “attack wave” one had drawn with some painting program, for example Deluxe Paint. If the drawn attack wave crossed itself, the problem which way to follow was solved by using different colors… Quite clumsy, but that’s me… 🙂 Anyway this program made possible an arbitrary possibilities of continuous attack waves (at least almost).
One early gem in the world of Amiga games is TheFaery Tale Adventure. It took quite a lot of time to finish this game. The labyrinth of the wizard took a lot of patience to get through. Fortunately one of my cousins was an expert to draw maps of games and had a lot of patience. 🙂
Below is a long play video of the game:
One game I played with my friends a lot was Ports of Call. Though this game is quite one-sided in a way that in practice it is best to use only the route between San Francisco and Cape Town. Though, with friends this game was still fun to play.
This game is nowadays available to PC and smart phones as free game.
As to strategy games, Kingdoms of England was fun to play with friends. Though, again there is one thing, that made this game in practice pointless: The choice of starting place in the map. There was one area in the map that as starting area gave the player too much advantage: The one who gets at the beginning of the game most tax income, will win the game, if one uses the resources one has in sensible way.
But again with friends this game was still fun to play, because we could as human players make agreement, that the one who had most advantage at the beginning of the game, wouldn’t attack human players, but only against computer’s troops. Another way to play this game in reasonable way, was to agree, that none of as human players don’t choose as starting area the area which makes it too easy to get more tax income at the beginning of the game a lot faster than others.
The sequel to Kingdoms of England, Kingdoms of England II: Vikings, has more elements as it comes to strategy. But there is one bug in the game: The computer as opponent can build a castle one playing turn faster than human players (it takes many playing turns to build a castle that can’t be built bigger anymore)…
A good game that taught a lot of strategy and sensible usage of resources is Empire: Wargame of the Century. Video below:
I wasn’t really into flight simulators, but with a friend Sky Chase was a good game; against computer the game was pointless: Too easy. When the game begins, the two plains are flying to opposite directions and the only thing one has to do to shoot down the computer controlled plane is, to turn one’s plain 180 degrees and fire. 🙂
A game I had a lot of fun with friends was North and south. The game has fine graphics and lots of humor too. 🙂
Shadow of the Beast was technically fine with excellent music. At first the game was very difficult, but eventually it got easier with practice, though I never finished it completely. I was only a few steps away from the end, but somehow I managed to fail. Though I saw the end: My friend managed to finish the game.
Just a quick mention of good game that I had only as demo from an Amiga magazine, namely nice mind game Bill’s tomato game.
At the time original and good view on teaching strategy — and sympathy to the poor lemmings — were the Lemmings games. Video below from the first Lemmings game:
A game that I still can’t believe is possible to implement on an Amiga 500 with only 512kb of CHIP memory is Turrican II. How on earth the programmers managed to implement all those many details, smooth scrolling, huge levels and so on — all happening in one 50hz frame! This game truly gave the player challenge for sometime! And the music of the game: One of the finest hours of Chris Hülsbeck on Amiga! It must be mentioned that in the intro there is 7 channel music, replay routine coded by the musician himself (Amiga has only 4 hardware channels).
One game was interesting in the way that some levels had completely different concept of gaming, namely Batman the Movie. The game is a mixture of a platform game, car game, flying game and puzzle solving.
As to racing games, the Lotus Turbo Challenge games were excellent. Video from second Lotus game:
Ah, one early gem in the world of Amiga games: Battle Chess. At the time I saw this game for the first time, I was still using good old Commodore 64. Seeing this kind of chess game on an Amiga 500 was amazing! Video below:
One game I almost forgot is Flood. If my memory servers me right, I had this game only as a demo, but it was something somehow new. Mind / puzzle game that was some how original at the time. See the video:
Well, that was something I can remember from my good old Amiga times… If I remember some more games I had fine moments with my friends, I may update this post later… Of course this is just a brief view back in time…
This one goes to nostalgia, old school and to my hobby corner. 🙂
Below is the video regarding this post:
The video starts with traditional old school 2D stars, then the video continues with 3D cube that has the 2D star field as texture. Each face of the cube is transparent, so you see the starfields of the cube from different faces at once… The cube fades into the background slowly…
I haven’t done much 3D programming in Blitz3D, but this kind of code is quite easy for a beginner like me to put together.
I remember, that in the good old Amiga days I saw an amazing Amiga demo, that had star field in rotating cube. Those Amiga demos were a lot more complicated to program, since they were low level assembly code using directly Amiga’s hardware. The idea to program this in Blitz3D came from one Amiga demo music remix tune, that has little speech in it: “A star field in a box. Oh my God, it’s rotating!” 🙂
For example in my Memorable Ladies games it is the case that I needed a method that gives a random integer for example between 0…31 so that any integer that has once been drawn, doesn’t get drawn anymore.
One way to handle this (how I didn’t do it) could be for example to use Rand-function (depending on programming language one is using) that gives an integer between n…m (m > n) and make a list of numbers that are already drawn and use Rand-function again between n…m, if the integer given by Rand has already been drawn.
But in the worst case this could lead to infinite loop… In practice probably not, though. In order to avoid the infinite loop (the case where Rand function gives repeatedly a number that has already been drawn), one could for example increase the drawn number by 1 until unused number is found or go on to m and if needed start from n and increase the value by 1 until unused number is found.
In Memorable Ladies games speed isn’t critical factor, when the numbers are drawn, so in this particular case the routine doesn’t necessarily need to be fast. In addition the amount of data can be considered very small.
What I came up, was something where every random number is (in practice) necessarily unique and without possibility to get stuck on infinite loop.
The idea goes like this:
Let us assume that we need n integers between 0….n – 1
Make a list of numbers with type ”number” where type ”number” has as a member an integer between 0…n – 1(the numbers can be in increasing order)
Draw an integer between 0…n – 1. Let this be i.
Get from the list ith ”number” element and get the integer that is in that ”number” element as a member and then delete that element from the list
Decrease n by 1
Repeat until list is empty
Even if in the original list of type ”number” the integers are ordered from 0 to n – 1, one would get this way an unique random integer each time (except if Rand gives zero (0) n times).
There are more sophisticated ways to do this, especially if the set of needed integers is large.
Image courtesy of Stuart Miles at FreeDigitalPhotos.net
For the sake of nostalgia… Let be mentioned what kind of random number generator I have used with Amiga with MC68040’s built-in FPU in assembly. As such this doesn’t give an unique random number, though.
(In the source code of my old Quest of Love demo you can see this in practice)
Let us assume, that we need an integer between 0…n.
Get the vertical beam value from $dff006
”Scale” the previous value with desired integer in order to get it big enough
Use FPU’s fsin instruction (sine function) to that value
Use FPU’s fabs instruction (absolute value) to the value we got in the previous step
Now we have a floating point value between 0…1
Multiply that value by n
Convert the value of previous step to integer
If we would like to have an integer between n…m (0 < n < m)the additional steps would be
Let z = m – n
Add z to the integer we got in the last step earlier
The two steps above are only the idea to get the value to the desired interval; in assembly there are not variables at all as we know them in programming languages of higher level.
This idea probably gives you a good idea how to get random integers with Monkey X’s Rnd() that gives a random value between 0…1. 🙂
Probably the most common way is to do something like following:
value = Rnd() * 100 Mod n
This gives a random integer between 0…n – 1 (0 < n <= 100 above). Notice that in the sentence above there are two possibilities to get zero: 1) Rnd() gives 0, 2) Rnd() gives 1 and n = 100.