Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / linux/unix/apple/consoles/opengl/ future of darkbasic???

Author
Message
Drake
20
Years of Service
User Offline
Joined: 15th Oct 2003
Location:
Posted: 12th Jun 2004 02:00 Edited at: 12th Jun 2004 02:28
hi

well DBC is still good enough for me, buttimes are change, especial in game development,to day windows is not only platform to play and develop games like it was in the past, today linux/unix/apple/consoles and openGL as API become biger and biger market for games every day, and what is the answer from DarkBasic kreators for this fact, will they create cross platform DarkBasic or they extinct like many others before them

so folks what do you think????
eat much pie
20
Years of Service
User Offline
Joined: 9th Apr 2004
Location: Within the mind of a lowly mortal...
Posted: 12th Jun 2004 02:17
This is my simple understanding of the situation:

Stuff made in DBPro is made into the .exe file format, ie. it's in machine code. Therefore it can be read by certain machines. If you want it to be read by another machine, I don't see why some kind of converter would be impossible to make.

However, to make games for consoles, you need a liscence from the creators of the console, HUGE expenses.

Checkpoint Router: my very own AI routing program: http://www.angelfire.com/theforce/eatmuchpie
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 12th Jun 2004 02:19
You can't just make a converter that converts one system's machine code to anothers. Take GameCube, for example. They're a little endian machine which requires a human being to manually port over, say, an Xbox game. I'm sorry, it just can't be done.

empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 12th Jun 2004 02:31
Quote: "They're a little endian machine which requires a human being to manually port over, say, an Xbox game. I'm sorry, it just can't be done."

Although I totally agree, it can't be done, I don't think that the byte order is a major problem.

Play Nice! Play Basic!
Zenincanin 14
20
Years of Service
User Offline
Joined: 14th Apr 2004
Location: In The Cat Lair at Peter Criss\'s House.
Posted: 12th Jun 2004 02:43 Edited at: 12th Jun 2004 02:45
Acctually, it is possible to make games for an X-Box. Though you have to qualify. You send them your game idead and if they like the idea they give you their software and 2 licenses to sell games. Then in 6 months you need to send Microsoft a demo of your game. Why you have to send a demo is because before they can give you 2 licenses they have to see your game. Here's the link:

http://www.xbox.com/en-US/dev/incubator.htm

Or yiu can check out some of the X-Box .EXE to .XBE converters. The thread is a locked thread and it's called "So, you wanna make XBOX games?". Search for it.

Good Games Are Made by Powerful Coders
]
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Jun 2004 02:51
hmmm ... well i think i'll let this topic go a bit futher before i comment on things.

what i would like to say though, not so much in part for multi-platforming; but i would like to see TGC changing the core of DBP.

Remarked commands for example should be handled by the compiler not the engine... you shouldn't have to rely on DirectX being initilised just to run it, not against the window however would be nice to use a pure console too.

and some other things that really would like to see; i think most of what the exec starts could easily be just part of the Core DLL and added if it is used; but if not then you could use other dlls that don't require the dependancy of the core dll would be great.

there does appear to be alot of crap added for no aparent reason;
you type 'exit prompt "",""' and notice the exported exe is 601kb,

now i know the file export is
64kb - exe
5kb+ - source code
systemdll - 64kb
coredll - 168kb

so where is the rest of that 601kb comming from?!

Zenincanin 14
20
Years of Service
User Offline
Joined: 14th Apr 2004
Location: In The Cat Lair at Peter Criss\'s House.
Posted: 12th Jun 2004 02:59
Hmm, good point.

Good Games Are Made by Powerful Coders
]
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 12th Jun 2004 03:19
Quote: "
so where is the rest of that 601kb comming from?!"

DBproSetup.DLL, DBproBasic2d.DLL and DBproText.DLL

DLL cross dependancies are a known issue.

Play Nice! Play Basic!
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 12th Jun 2004 20:01
Empty, explain to me why you would need 5 DLLs just for a single command which is part of Windows API, that accepts plain strings?

I can understand core as the DirectX main window is setup from the get go; and System becuase that's the DLL that covers the function.
But what the hell does Setup, Basic2D and Text be needed for?

I keep seriously wondering about the strings used in DarkBASIC Professional, hell all of the variables used. There SHOULD be no dependacy for this stuff...

Strings should be being handled by the compiler! What the hell is the compiler ACTUALLY creating?!

OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 12th Jun 2004 20:10
Its probably code for displaying text, assigning text to strings and what-not...


The place for wonderful plug-ins and things.
Keep your friends close, and your cats even closer.
the_winch
21
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 12th Jun 2004 20:29 Edited at: 12th Jun 2004 20:32
Quote: "Empty, explain to me why you would need 5 DLLs just for a single command which is part of Windows API, that accepts plain strings?
"


empty explained that.

Quote: "DLL cross dependancies are a known issue."


The compiler appears to decide what dlls to include on a dll basis not a command basis. The exit prompt command is in a dll with lots of other commands. If any of the other commands in the dll require other dlls the other dlls will be inculded.

If you write your own tpc msgbox function you can get the exe size to ~250kb

can i scream
Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 12th Jun 2004 20:47
@Raven

the_winch is correct. What needs to be included is decided on a DLL to DLL basis. In order for a DLL to call a command from another DLL it has to have it's import field field out with Thunk Table for that DLL(among other things).

Since the window's loader needs to be able to find all DLLs in the import section of the DLL the DBPro compiler has to include them all in. Otherwise you'd get an error stating you couldn't find DLL such-and-such when you try to start the program even though the commands that are in that DLL are never used.
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 12th Jun 2004 21:19
Quote: "Since the window's loader needs to be able to find all DLLs in the import section of the DLL the DBPro compiler has to include them all in. Otherwise you'd get an error stating you couldn't find DLL such-and-such when you try to start the program even though the commands that are in that DLL are never used."

True, but this problem could be avoided by late-binding. However cutting down cross references to a minimum would be a better solution.

Play Nice! Play Basic!
Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 12th Jun 2004 21:33
@empty

"but this problem could be avoided by late-binding."

Yeah, but I don't think Lee knows how to do that.

"However cutting down cross references to a minimum would be a better solution."

Or even better, turn all of the .DLLs into .LIBs and build a linker. That would make the .exes substantially smaller. It'd be as small as they could be(uncompressed) probably.
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 12th Jun 2004 22:12 Edited at: 12th Jun 2004 22:12
Quote: "Yeah, but I don't think Lee knows how to do that. "

But there's LOAD DLL and CALL DLL...


Quote: "Or even better, turn all of the .DLLs into .LIBs and build a linker. That would make the .exes substantially smaller. It'd be as small as they could be(uncompressed) probably"

That would make writing TPCs in Delphi more difficult, so that's a bad idea.

Play Nice! Play Basic!
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 12th Jun 2004 22:45 Edited at: 12th Jun 2004 22:46
Quote: "Although I totally agree, it can't be done, I don't think that the byte order is a major problem. "


Actually this is what takes up the largest chunk of time in porting to GameCube from Xbox/PS2.

I hope you're joking by the smilie so I'll shut up now heheh...

Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 12th Jun 2004 22:48
@empty

"But there's LOAD DLL and CALL DLL... "

True. But he'd have to have some way of only loading them in once, otherwise we'd be loading in DLLs constantly everytime a command is called.

There in lies the difficult part. Only loading in the DLLs once and when you need them.

He'd also have to have some kind of system for selecting which DLLs get loaded in initially or we'd have some serious slow down in the beginning and some rather unpredictable slow downs whenever a command is called for the first time.

Sounds like it'd just be easier to go the linker route(which, coincidently, I happen to be aiming for myself with my Basic4GL compiler. ) But that's just my humble opinion.

"That would make writing TPCs in Delphi more difficult, so that's a bad idea."

You could still bind in TPCs the normal way. Just leave the DLLs that come with DBPro as .libs. Its highly unlikely he'd do that anytime soon though.

But from what I hear there are problems with 64 bit Windows and DBPro .exes. It keeps thinking that its a virus everytime it starts up. Some new security feature. I'm not surprised though. Given the non-standard way in which DBPro loads code it does make it look rather suspicious.

In the end, Lee probably will have to make geniuine .exes and not tack on the code at the end like he is currently. Considering how much of a pain it is going through these things and figuaring out how to do that, I could see him going the easier route and just generating an .obj file and using a free linker to create the .exe for him.

If he ends up doing that, the .lib idea might not be so far fetched after all.

But that is all just guess work. Until Lee starts working on the compiler, I suppose we are just going to have to deal with clunky file sizes for the time being.
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 12th Jun 2004 23:42
@Jeku
Quote: "Actually this is what takes up the largest chunk of time in porting to GameCube from Xbox/PS2.
I hope you're joking by the smilie so I'll shut up now heheh..."

Yeah, that was directed (compared) to porting DBpro executables (DirectX) to OpenGL on machine code level.



@neophyte
Quote: "There in lies the difficult part. Only loading in the DLLs once and when you need them.
He'd also have to have some kind of system for selecting which DLLs get loaded in initially or we'd have some serious slow down in the beginning and some rather unpredictable slow downs whenever a command is called for the first time."

That's not too difficult. Even with the current system the compiler can find out which DLLs are needed. So it has to add a list of required DLLs and functions to the executable. On start up the exe loads the dlls, searches the function addesses and stores them in a list. It'll be slightly slower than early binding, but it won't be that bad. Each TPC DLL would have to export a list of the DLLs it requires, though.


Quote: "Sounds like it'd just be easier to go the linker route(which, coincidently, I happen to be aiming for myself with my Basic4GL compiler. ) But that's just my humble opinion. "

Yeah, that's certainly the most elegant way. Although I'm afraid that PE files (as they're currently used) are a dying creature.



Quote: "But from what I hear there are problems with 64 bit Windows and DBPro .exes. It keeps thinking that its a virus everytime it starts up. Some new security feature. I'm not surprised though. Given the non-standard way in which DBPro loads code it does make it look rather suspicious."

The method is widely spread actually (Blitz does it the same way). Interestingly MS's .Net JIT compiler had the same problem with the first versions of Windows XP SP2. According to MS it's a problem of wrongly tagged allocated memory.


Quote: "In the end, Lee probably will have to make geniuine .exes and not tack on the code at the end like he is currently. Considering how much of a pain it is going through these things and figuaring out how to do that, I could see him going the easier route and just generating an .obj file and using a free linker to create the .exe for him."

Or wait for .NET's break-through. I'm not a big fan of it, but I'm sure it will succeed.

Play Nice! Play Basic!
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 13th Jun 2004 00:24
Quote: "Actually this is what takes up the largest chunk of time in porting to GameCube from Xbox/PS2."


Take it the company you work for has never heard of Codewarrior?
if you have GCC
+e0 = Little Endian
+e1 = Big Endian

it is as simple as that; why exactly would you go and hand code everything to flip?
i'm also pretty sure there is some sort of pragma for it as well because you can do it in Visual C, but i've not needed to so never checked.

as for the explaination... if you need 5 DLLs for once task that isn't a problem; that's stupid programming. depedancies (really shouldn't be part of the DLLS) should be part of a seperate smaller DLL to prevent bloating.

the more i look and hear what each person who has delt with dbp has to say; just looks more and more that this is mearly a scriptable engine and not an actual language.

Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 13th Jun 2004 01:24
@empty

" Each TPC DLL would have to export a list of the DLLs it requires, though."

Yeah, I was thinking of that as I posted. Wouldn't you have to make the DLLs as delay import as well? I mean, there is a field somewhere in the file format for them that specifies that. It was either in the Optional Header(probable) or PE Header(Improbable, but still possible. I forget). Otherwise loading them in would just cause Windows to go searching for their dependicies defeating their whole purpose. Or not?

I haven't really looked into the whole delay import thing that closely. I saw some fields in the PE file format for them, but I read that it had to be handled manually and that there was some DLL that came with VC++ that did it or something like that. So I lost interest and moved on to something more relevant.

Does windows enforce the loading of other dependent DLLs when you load them in manually? If they do then I'm sure Lee would have to change the current DLLs so they were all tagged as delay-import. Not too big of a deal of though.

"The method is widely spread actually (Blitz does it the same way)."

Yeah, I know. You told me once.

"Interestingly MS's .Net JIT compiler had the same problem with the first versions of Windows XP SP2. According to MS it's a problem of wrongly tagged allocated memory."

Interesting. I hadn't heard about that.

"Or wait for .NET's break-through. I'm not a big fan of it, but I'm sure it will succeed."

Yes, but I guy can dream can't he?

*dreams of a .LIB future of real small executables*

@Raven

"the more i look and hear what each person who has delt with dbp has to say; just looks more and more that this is mearly a scriptable engine and not an actual language."

What about it makes you think that? Clunky file sizes? VB had that once but it was still considered a language.

I don't get where you are coming from here.
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 13th Jun 2004 01:30
run a basic dbp program, while it's running grab the dbptemp data and look at the _virtual.dat - provided you understand you ASM you'll see exactly what i mean.

Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 13th Jun 2004 01:37
@Raven

"while it's running grab the dbptemp data and look at the _virtual.dat - provided you understand you ASM you'll see exactly what i mean."

Sure. I'll give it a go when I find the time.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 13th Jun 2004 01:45
A simple exe file with just a 'wait key' will do. Run it in window mode, then while it's running look for the folder and its contents.

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 13th Jun 2004 02:09
Okay, I've nicked a copy of one. I've ran it through a disassembler but I keep getting some junk instructions...in the beginning. There seems to be a couple of string at the start of it so that's what could be causing it.

After that there does seem to be quite a few legit instructions but I'm not sure if its just garbage as well. The disassembler reads the strings as instructions although the code produced didn't make any sense.

Any clue as to what this is? It looks like a combo of the names of the needed DLLs that have to be loaded and the machine code for my program as well as some strings for error codes later on. Or is that guess not even close?
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 13th Jun 2004 03:03 Edited at: 13th Jun 2004 04:03
Quote: "Yeah, I was thinking of that as I posted. Wouldn't you have to make the DLLs as delay import as well? I mean, there is a field somewhere in the file format for them that specifies that. It was either in the Optional Header(probable) or PE Header(Improbable, but still possible. I forget). Otherwise loading them in would just cause Windows to go searching for their dependicies defeating their whole purpose. Or not?"

Right delayed DLL loading is one way. ALthough that seems to be as fast as dynamically loaded DLLs. It just saves a few lines of code. When I said "Each TPC DLL would have to export a list of the DLLs it requires, though" I wasn't very clear. I meant, that the DLLs would need to export a "required" list for each function. Via StringTables for example (as the compiler uses them now as well).


Quote: "
"Interestingly MS's .Net JIT compiler had the same problem with the first versions of Windows XP SP2. According to MS it's a problem of wrongly tagged allocated memory."
Interesting. I hadn't heard about that."

That was made public when RC 1 was released. Will try to find the link (IIRC heartbone posted in on LLRGT).


Quote: ""Or wait for .NET's break-through. I'm not a big fan of it, but I'm sure it will succeed."
Yes, but I guy can dream can't he?
*dreams of a .LIB future of real small executables*"


I know how much research and work it requires to create a linker, so... all the best for your project.



Quote: "run a basic dbp program, while it's running grab the dbptemp data and look at the _virtual.dat - provided you understand you ASM you'll see exactly what i mean."

That was my first (and probably even second) thought too. During one of the recent IRC sessions Mike's guess was that the file is used for debugging stuff. After some further experiments I tend to believe that too.

Play Nice! Play Basic!
Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 13th Jun 2004 03:16
@empty

"When I said "Each TPC DLL would have to export a list of the DLLs it requires, though" I wasn't very clear. I meant, that the DLLs would need to export a "required" list for each function. Via StringTables for example (as the compiler uses them now as well)."

Okay. I understand now.

"I know how much research and work it requires to create a linker, so... all the best for your project. "

Thanks.

I've made quite a bit of progress recently and its looking like my dream might just come true. Well, for Basic4GL anyway.
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 13th Jun 2004 03:21 Edited at: 13th Jun 2004 03:22
XP SP2 and .Net JIT
http://www.infoworld.com/article/04/03/04/HNwindowsxpsp2_1.html
Tony Goodhew, a product manager in Microsoft's developer group:
Quote: "
"The great bulk of applications will not be affected by memory protection. The number one that leaps to mind is execution environments with just-in-time code generation. The .Net Framework is one."



Memory Protection (More details)
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx

Quote: "Applications that require executable regions of memory must use the PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY attributes when allocating memory. Additionally, applications cannot execute from the default process heap or the stack. Most applications that perform actions incompatible with data execution prevention will need to be updated to be compatible."

Interesting, since these attributes have been available since Windows 95.

Play Nice! Play Basic!
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 13th Jun 2004 06:49 Edited at: 13th Jun 2004 23:04
Quote: "Take it the company you work for has never heard of Codewarrior?"


Well I'd imagine everything they (EA) use here is the best and most expensive.

Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 13th Jun 2004 07:12
@empty

Thanks for the links.

"Interesting, since these attributes have been available since Windows 95."

Yes. One would wonder why they didn't bother to enforce this earlier.

But on the bright side, at least they are finally becoming more concerned with security.
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 13th Jun 2004 16:24
lol Jeku... EA Pacific where i used to work used Visual Studio for everything; they prefered Microsoft for everything.
Remember having a chat with one of the programmers about it once, he was like 'Well we swapped over to DirectX for a redevelopment of an old title for the new Windows 95 OS. It made everyone's lives a hell of alot easier, so we also swapped from Borland C and found we got finished recoding an entire game in 3months which originally took 18months.'

Quote: "<POST REMOVED DUE TO PARANOIA>"

LOL, i wonder if i can bribe puffy to tell me what the original post said.

empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 13th Jun 2004 21:52
Quote: "Yes. One would wonder why they didn't bother to enforce this earlier."

And why they haven't used it in their own products....

Quote: "But on the bright side, at least they are finally becoming more concerned with security."

Yes. Quite late but still...





Quote: "EA Pacific where i used to work"

C&C Generals and the lost credits, yeah I know.

Play Nice! Play Basic!
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 13th Jun 2004 23:00
Quote: "LOL, i wonder if i can bribe puffy to tell me what the original post said."


Hehe believe me that said nothing important (I'm just a paranoid nut), it's just I don't want to say anything about anything that involves work on messageboards. I've heard horror stories of them showing up later to haunt people.

Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 13th Jun 2004 23:09
lol tell me about it Jeku... just look at the post above your own.
always a problem with a forum with some people who are just well jerks.

if you want a place where you can swap work stories just goto polycount.com - it is kinda freaky how many guys work around the industry stop by there just to do freelance work.

i still wanna know where Rouge13 is working now, i know it's in texas and on a big project but he's being all hush-hush - just not like him, when he was working on planetscape we got blow-by-blow reports hehee

Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 14th Jun 2004 02:29
Hehehe that's funny, blow-by-blow reports :p Now *that* is risky, especially since anyone in the industry has to sign NDAs and could get sued.

Polycount? Cool, I've been looking for another forum that's not as ridiculous as this one can get. I've recently been lurking around the AGS forums for adventure game nuts like myself who create indie adventure games.

MikeS
Retired Moderator
21
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: United States
Posted: 14th Jun 2004 06:01
Agreed Jeku. I find GameDev one of the best forums to hang around. I don't post to much, but I do read a lot of the articles and forum posts daily.



A book? I hate book. Book is stupid.
(Formerly known as Yellow)
Guhill The friendly one
20
Years of Service
User Offline
Joined: 12th Jun 2004
Location: The fourth demension
Posted: 14th Jun 2004 06:42
Drake, you spelled bigger wrong.

I know now, without a doubt, that Kingdom Hearts... IS LIGHT (Sora)
DMXtra
22
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 14th Jun 2004 08:47
The answer to Microsoft cross platform domination as well as DBPro's future?

XNA

Makes a lot of sense with Direct X Next which is a part of XNA itself.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Jun 2004 16:10
yeah XNA is definately exciting for alot of Microsoft users in terms of being able to use it on any hardware.

Quote: "Hehehe that's funny, blow-by-blow reports :p Now *that* is risky, especially since anyone in the industry has to sign NDAs and could get sued."


depends what the NDA says really.if you read them carefully alot of the time it just excludes things you can talk about... i believe for planetside Rouge13 was just not allowed to talk about features, so he could sit there and show us levels as he developed them.

i think for indi adventure games, ScummVM is one of the best engines

Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 14th Jun 2004 23:20
I use ScummVM all the time to play my old LucasArts games

But how does it work with indie games?

Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 15th Jun 2004 00:51
http://scummvm.sourceforge.net/

I think the documentation explains howto create Scumm Scripts, after all Scumm is a scripter engine; and what ScummVM does is translate that into Windows/Linux.

as i said check the documentation because if i recall it covers everything pretty well on howto use the engine

Login to post a reply

Server time is: 2024-09-22 02:52:36
Your offset time is: 2024-09-22 02:52:36