Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Antiquity
#1
After breaking the QBasic compiler by having too much code and not being able to put it into libraries, I decided to do this project in Freebasic instead. Now there are no tricky Future library XMS work arounds thanks to *almost* unlimited memory.

Six days and 80kb of 90% new code later, rewriting the memory, graphics and core components I have my first release of this Civilization style game.

This game was originally created by Kristoffer and Sune Olsen. It and its pascal source code were released as freeware and I've used the original graphics file (so dont blame me if you cant work out the graphics) and rule set.

The game itself was never finished, reaching alpha status with no AI. As yet I am still quite some time from getting to that stage, and then hopefully past it, adding some form of AI.

I need to rewrite the graphics, at the moment its doing (equivalently) over 256,000 PSET's a frame. Hence even on a fast computer you may only see a few frames per second and a delay in the input to result.

The game can be downloaded here at http://ucc.gu.uwa.edu.au/~undertow/pub.zip and I strongly urge you to read the README.TXT (not comprehensive but perhaps enough to get the feel of the game) because the game is similar but rather different. Don't get too attached to the game because you cant save/load yet.
Important: This game uses SDL, so make sure you have the DLL file.
Reply
#2
[half pseudo code thingy]

Surface = SDL_CreateRGBSurface
PSET images to surface

Do
SDL_BlitSurface 'image to screen
Loop

[/half pseudo code thingy]
Reply
#3
Really cool, ran at ~50 fps here, even doing all with PSET, ow ;)

You ported it from pascal or had a pre-working QB version? I guess the code is quite complex..
Reply
#4
Quote:[half pseudo code thingy]

Surface = SDL_CreateRGBSurface
PSET images to surface

Do
SDL_BlitSurface 'image to screen
Loop

[/half pseudo code thingy]

It actually seems to go a couple of FPS slower although the advantage in this method is that it no longer needs to lock and unlock the surface.
I've now made it so that it only updates when it needs to instead of just drawing frame after frame.
Reply
#5
Quote:Really cool, ran at ~50 fps here, even doing all with PSET, ow Wink

You ported it from pascal or had a pre-working QB version? I guess the code is quite complex..

I'm up to 108 subs and functions and still counting! I've separated it into 9 files with one well organised header file so it helps me find where they all are. As I'm sure you can imagine debugging is a nightmare.

I ported it from pascal to QB but the code had to be modified as it used OOP. The FB port is much different to the QB version because I no longer need the Future library routines to get around memory problems etc. Its actually starting to look very C ish.
Reply
#6
I've finished as much as I'm willing/able to do at the moment. Its 95% playable, but no AI. I've also released the source code. If anyone is willing to help complete it, then by all means go for it. I've also made an incomplete web site with some basic documentation to it.

The code is messy but i have tried to make it as readable/logical as possible. Apart from this I hope someone likes the concept behind the game (remembering I didn't do the graphics).

The documentary/source/game is available at :
http://undertow.ucc.asn.au or
http://www.ucc.gu.uwa.edu.au/~undertow/

Thanks v3cz0r, nothing seemed to go wrong compiler side for over 200kb of code, anothing FreeBasic success story.
Reply
#7
Make sure you make the surfaces HWSURFACE, and fullscreen video.

Windowed mode you never know what you get, as windows still controlls it.
And SDL will emulate the color depth and hw acceleration (there is no hw accel)

So, 32bit on a 16bit desktop will be way slower than 32bit in fullscreen. Or 16bit on a 32bit desktop.


Also, some gfx cards support HW blitting, which speeds blitting up a lot.
Reply
#8
looks cool, runs smoothly here, keep up good work!
url]http://fbide.sourceforge.net/[/url]
Reply
#9
Quote:Make sure you make the surfaces HWSURFACE, and fullscreen video.

Windowed mode you never know what you get, as windows still controlls it.
And SDL will emulate the color depth and hw acceleration (there is no hw accel)

So, 32bit on a 16bit desktop will be way slower than 32bit in fullscreen. Or 16bit on a 32bit desktop.


Also, some gfx cards support HW blitting, which speeds blitting up a lot.

I couldn't get the mouse to show in fullscreen mode using SDL_ShowCursor, so I settled for windowed. Perhaps that isn't the correct command to use.
Reply
#10
Nothing wrong with windowed, and nothing wrong with plotting individual pixels either.

Code:
result = SDL_ShowCursor ( 0 )
0 = Hide
1 = Show

You can ignore result:
Code:
SDL_ShowCursor ( 1 )
Mouse cursor is visible by default in SDL.

To get the mouse position and which button is being pressed:
Code:
Dim XMouse as integer
Dim YMouse as integer

MouseBTN = SDL_GetMouseState(@XMouse, @YMouse)
Would retreive mous x and y position, and which buttons are being pressed.

Note though, that:
Left mousebutton = 1 (bit 1)
Center mousebutton = 2 (bit 2)
Right mousebutton = 4 (bit 3)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)