Messages

It's even more amazing how such simple games can attract huge amounts of money, too!
It's totally mindblowing, having $0.99 app selling by hundreds of thousands, even millions. Promised land for everybody, really.
It's just a bit problematic to get noticed there, but once you are seen and have a decent game at least - capitalism works its magic!

Anyway, I radiate motivational waves from my brain towards Germany.... make iPhone compiler..... make iPhone compiler.....

Code (glbasic) Select Expand

TYPE animal:
    type = "sheep"
    ...
ENDTYPE

I did it like that. It's kind of double-workaround and it leaves A LOT of space for logical errors and other nasty stuff, but hey, it works!

Here's the revised code:

Code (glbasic) Select Expand


SETSCREEN 640, 480, 0

GLOBAL sheep AS animal
sheep.kind$ = "sheep"
GLOBAL dog AS animal
dog.kind$ = "dog"


PRINT "Which animal (sheep or dog):",0,0
LOCAL an$
INPUT an$, 0,10

IF an$ = "sheep" THEN eat_grass (sheep, 12)
IF an$ = "dog" THEN eat_grass (dog, 2)


SHOWSCREEN
MOUSEWAIT


TYPE animal
health
kind$
ENDTYPE


FUNCTION eat_grass: s AS animal, a

IF s.kind$ = "sheep"
FOR i = 1 TO a
PRINT "Yum! Yum!", 0, i*20
NEXT
ENDIF

IF s.kind$ = "dog"
PRINT "I ain't eating no grass, dammit!",0,0
ENDIF

ENDFUNCTION


[s]

It would be a killer feature, as it is difficult to go back once you taste the benefits of OOP.



@Gernot:

Is there a way to make function avare of which "instance" of TYPE it was called from?
ie. can the function know whether it was called from a sheep or a dog animal?

Code (glbasic) Select Expand


SETSCREEN 640, 480, 0
GLOBAL sheep AS animal
GLOBAL dog AS animal

PRINT "Which animal:",0,0
LOCAL an$
INPUT an$, 0,10

IF an$ = "sheep" THEN eat_grass (sheep, 12)
IF an$ = "dog" THEN eat_grass (dog, 2)

SHOWSCREEN
MOUSEWAIT

FUNCTION eat_grass: s AS animal, a
IF s = sheep
FOR i = 1 TO a
PRINT "Yum! Yum!", 0, i*20
NEXT
ENDIF

IF s = dog
PRINT "I ain't eating no grass, dammit!",0,0
ENDIF
ENDFUNCTION

TYPE animal
health
ENDTYPE


This example produces some weird results, since s is both sheep and dog at the same time...

Would it be possible to have functions inside TYPE, something like this:

Code (glbasic) Select Expand


TYPE animal
        size
        weight
        health
        FUNCTION eatsomegrass: a
            for i =  1 to a
                   print "Yum,yum!!",0,a*10
            next
        ENDFUNCTION
ENDTYPE


GLOBAL sheep AS animal
sheep.eatsomegrass: 12




This would be a step towards object oriented approach in GLB.
I guess there's a lot to be done "under the wraps" and things probably aren't as simple as I'm trying to make them look... but still, it would be nice to have this feature.

FBX and Collada are basically industry standard these days.

Google is developing this new opensource plugin which wraps native C/C++ code and makes it deployable to web browsers. It already supports SDL - Quake has been ported.

There's obviously a huge potential for GLBasic to develop browser-based executables.

Here's what's it all about:
http://arstechnica.com/news.ars/post/20081209-safer-than-activex-a-look-at-googles-native-client-plugin.html
http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html

Moru, thanks for this little demo, at least now I know it is possible. It works fine here, but I have 512mb card. What worries me is memory usage, as you said it's 192MB just for those four 1024 tiles, and I would need at least 9 loaded at the same time to produce seamless terrain effect (I am counting on 1024x768 screen resolution or more, minimum graphics card it must run on should be Intel GMA950). And than at top of that come various sprites like characters, animations etc. I somehow think I set my goals too high, sadly.

I was thinking about this today (that's why discussion is important - it makes you think!!  ). I may go for a "hybrid" approach to this. I think I'll spread the terrain into smaller tiles, ie. 128x128 or 64x64, and then on top of that do what you suggested in the firs reply - draw various objects on screen as they appear (trees, pillars, etc).
That way things can be further optimized: I can find out what tile the character is on and just draw additional objects there, while all other "unoccupied" tiles are drawn just as background.

And if I have for ex. 8192x8192px terrain, separated into 128x128 pixel tiles, thats 64x64 = whooping 4096 tiles! All different and unique! (now there's a clear difference between tile-based and prerendered backgrounds)
Obviously I can't load them all into memory, so there must be some streaming going on from the hard drive. Putting them into two-dimensional array and shifting it in appropriate direction when needed, or something.

Ok, I think I dabbled way too much words here, I think I have to go and code something out of this to find out what works and what doesn't, but if someone has to add something useful or maybe steer the whole thing in another direction, please do so... let it be for the benefit of the community.

And one more thing. Being of a more designer/artist background (now you know why so many words  ) and with BASIC being the only language I ever managed to turn into something meaningful.... if I come on with some obviously stupid programming questions, don't go hard on me, please. 

That was my idea at first also, but I don't know how practical that option is. That's the standard procedure for tiled games allright, but we're talking prerendered backgrounds here and that means not much data is repeated as in tile games where you can reuse "grass tile" or "tree tile" many times in one map. In prerendered you may have an entire forest the characters must walk through, or a castle you could walk behind, or an entire city (check Baldur's Gate screenshots). Now consider that castle could as well be 1024x1024px big, or that forest could be even bigger. Then you have A LOT of data, which is drawn using graphics card texture memory, and there you run into problems. Not to mention that precise placement of all that different sprites would be a major PITA.

I actually considered using huge (1024x1024) tiles for backround (layer 0) then characters layer (with smaller sharacter sprites), and then on top of all that another 1024x1024 alpha-mapped tileset to serve as "walk-behind" mask (treetops and such). Those 1024 tiles would be streamed from hdd as character moves close to them.
Then I run it all through a calculator and came to an incredible huge amount of texture memory needed, and I just can't require 512mb graphics card for 2D tech demo!

Now, my instinct tells me there's more rational solution out there...

By now everybody must have played or at least heard about the great 2d isometric RPG's of the late 90s/early 2000s which were all the rage on the PC back then.To be precise I'm talking about games that used Infinity Engine, the series of games that started in 1998 with Baldur's Gate and ended in 2002 with Icewind Dale 2.
You may read about them here: http://www.mobygames.com/game-group/graphics-engine-infinity-engine and also here: http://en.wikipedia.org/wiki/Infinity_engine.

What I'd like to discuss is actual technical implementation of the engine if done in GLBasic. I'm not thinking of complex RGP game mechanics in general (inventory, dialogue and combat system) but just of graphical part of the engine.
In Infinity they used 2d sprite masks basically for everything. They started with prerendered background image, then there were smaller bitmaps drawn in solid colours to define walkable areas, height maps, shadow maps etc. There were masked aread for animations such as streams of lava or fountains and most importantly, masks that defined walk-behind areas (for example when a character walks around the back of the house and is covered by it).
It is important to mention this is not an tile-based isometric engine (like in Fallout or Ultima series), although it seems like it. This is technically more common to 2D adventure games of early 90s.

I was wondering how would this be possible to implement in GLBasic, considering it uses 3D as base for 2D graphics. We may start with solution to displaying huge backgrounds (that went up to 8000x8000 pixels or more) - some kind of tile-engine would be logical to use. Then we may go on to masking areas (this could be done with polygons, since I don't believe pixel maps are viable in an OpenGL engine). Then to pathfinding etc etc.
Discuss!!


ps. Oh, and you got great language and community going on here, nice to meet you all. 

Is there going to be full 3D support for WIZ, since it does have proper hardware acceleration?