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.

DarkBASIC Professional Discussion / Some DBPro complaints...

Author
Message
iaretony
21
Years of Service
User Offline
Joined: 6th Jun 2003
Location:
Posted: 31st Mar 2004 01:38
Link
Here are some issues I have with DBPro... These are, as I see it, the biggest stumbling blocks when trying to use DBPro to actually make something real.

1) Sytem Requirements. I recently finished a game that had barely any 2D animation, and NO 3d animation. My old 386SX from 1993 could have easily run the game (even as a windows program). Of course, implemented in DBPro, it requires DirectX9 and a graphics card with 16MB of ram and 3D hardware accelertion. These would be fine specs if I was aiming at the Gamer market, but my target market was the casual gamer with a 3-4 year old computer. Maybe I should have built a game with flashier graphics, so that I could target the hardcore gamer market? Yeah right! Their is about a 0% chance a lone developer can make a whole game that would meet the expectations of that market. As an "indy" game developer, we have to target games smaller in scope, that have broad appeal.

2) I have a feeling that the language itself cannot support large projects. Their certainly may not be any limit on the number of lines of code you can write, what I mean is that the language is missing a few key elements that make good structured coding possible. The one I remember most was passing TYPE's to functions by reference. This is a necessity, and it's missing. This is another factor that seems to say that DB should be used for smaller games.

3) Their is no error handling mechanism. I just recently finished a SlideShow viewer and when the user points the app at a corrupt image file, my code gets no chance to handle the error gracefully. The app simply exits with a error dialog. Maybe they chose to leave out error handling to make the language simpler, and theirfore easier for beginners... I don't know...

All in all, DBPro seems like a great language for making short demos, and for teaching SOME aspects of programming to beginners. Don't get me wrong, when I was 12, I would have LOVED DBPro... I don't question it's merit as an educational tool, I question it's ability to ship solid products.

What does everything think? I didn't mean this post to be a flame, as I explained, their are plenty of things I like about DBPro...

Tony

[email protected] - [email protected]
Back to top
Profile PM
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 31st Mar 2004 02:53
Link
"Of course, implemented in DBPro, it requires DirectX9 and a graphics card with 16MB of ram and 3D hardware accelertion. These would be fine specs if I was aiming at the Gamer market, but my target market was the casual gamer with a 3-4 year old computer."

Your assertion that casual gamer's with 3-4 year old PCs can't run DBPro games is false. The Nvidia Geforce 256 came out around August 31, 1999. That is more than four years ago and it has 32mb of video ram. More than twice the requirement.
Source:http://www.leadtek.com/geforceddr.htm
Source:http://www.nvidia.com/object/IO_20020111_5406.html

"I have a feeling that the language itself cannot support large projects"

Your "feeling" is wrong. Talk to Andy Igoe. He's written several projects that are in excess of 100,000 lines.

Driving Test Success Practical(not written by Andy) had over 21 thousand lines of code and it was written in DBC which has even less features than pro.
Source:http://darkbasicpro.thegamecreators.com/?gf=newsletter_issue_11

" The one I remember most was passing TYPE's to functions by reference. This is a necessity, and it's missing. This is another factor that seems to say that DB should be used for smaller games"

Its not a necessity. A necessity is something you can't do without and you can do without passing by reference though it would be nice. Besides, since you said yourself that there is a 0% chance of an indy developer succeding in the hardcore market wouldn't that negate the supposed "necessity" of passing by reference since smaller games can get away without it(and DBPro is only for making smaller games according to you right?).

"Their is no error handling mechanism. I just recently finished a SlideShow viewer and when the user points the app at a corrupt image file, my code gets no chance to handle the error gracefully. The app simply exits with a error dialog. Maybe they chose to leave out error handling to make the language simpler, and theirfore easier for beginners... I don't know..."

This is true. Some kind of error handling would be nice, but you can work around this yourself.

"I don't question it's merit as an educational tool, I question it's ability to ship solid products."

Than you obviously haven't looked at the showcase. If you want further proof of DBPro's capablity to ship solid products have a look here:http://www.bansheestudios.com/games/games.htm
Back to top
Profile PM
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 31st Mar 2004 03:53
Link
1) Yes, I can see your point, this has been debated at length - if you look around the forum you'll find past discussions on the subject.

2) My biggest stumbling block as far as the language goes is the inability to have arrays in types, but yes Pass-By-Reference would indeed be nice, although its perfectly possible to write large games without that feature.

Of course, if you use IanM's C++ integration lib this is no longer an issue.

3) Agreed, I would really prefer behaviour like the Windows API where, for example, an error results in a function returning null and GetLastError() can be used to get the details. In DBPro's case:

load image "potentially_corrupt.jpg",1

if image exist(1)
....
endif

BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games. - Plus URL download, win dialogs.
Over 140 new commands
Back to top
Profile PM Email Website
CloseToPerfect
22
Years of Service
User Offline
Joined: 20th Dec 2002
Location: United States
Posted: 31st Mar 2004 04:21
Link
all good point and all debated over and over and over on the forums before.

RGT may be gone but the best DBP forum is still alive and kicking, check it out.
http://www.dannywartnaby.co.uk/rgt/
Back to top
Profile PM Email
Dark Serpent
21
Years of Service
User Offline
Joined: 24th Feb 2004
Location: U.S.A.
Posted: 31st Mar 2004 06:07 Edited at: 31st Mar 2004 06:08
Link
OK guys! I hang on to this idea alot. THis may be a little off subject but have you ever beat a video game and looked at yhe sredits...I seeee there are a lot of people ...(most of which are doing only one thing for the game) DB in general can generate exelent games by just one person. If its not perfect...SO WHAT. (In my opinion.) Well then again you dopay top dollar. Sorry bout spelling.

I'm such a
Back to top
Profile PM
iaretony
21
Years of Service
User Offline
Joined: 6th Jun 2003
Location:
Posted: 31st Mar 2004 07:05
Link
"Your assertion that casual gamer's with 3-4 year old PCs can't run DBPro games is false. The Nvidia Geforce 256 came out around August 31, 1999. That is more than four years ago and it has 32mb of video ram. More than twice the requirement.
Source:http://www.leadtek.com/geforceddr.htm
Source:http://www.nvidia.com/object/IO_20020111_5406.html"

Hmm... Well, I have a shuttle cube that DBPro apps won't run on. It's about 2 years old. I also have a brand new laptop that runs DBPro apps like a pig (it's a 2 ghz celeron)...

My mom certainly has a computer from about 4 years ago, and it doesn't have a 3d capabilities. How many of those Geforce4's that came out were upgrades for Gamers... IE, not my target...


"Your "feeling" is wrong. Talk to Andy Igoe. He's written several projects that are in excess of 100,000 lines. "

Well, that's great for him. But how many people are doing this? What's wrong with rocking the boat a little to try to get some positive change?

"Driving Test Success Practical(not written by Andy) had over 21 thousand lines of code and it was written in DBC which has even less features than pro."

At a job I had in 1999/2000 their was a file in the tree that had 18000 lines of code. 1 File, amongst thousands in the tree.

" The one I remember most was passing TYPE's to functions by reference. This is a necessity, and it's missing. This is another factor that seems to say that DB should be used for smaller games"

Oh, OK. You know whats not a necessity either? Everything invented after punch cards.

You know what, never mind. Enjoy DBPRO. It's all yours.

Tony

[email protected] - [email protected]
Back to top
Profile PM
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 31st Mar 2004 08:16
Link
@iaretony

"Hmm... Well, I have a shuttle cube that DBPro apps won't run on."

Err...so? What graphics card does it have? Or does it have some kind of integrated graphics chip?

" I also have a brand new laptop that runs DBPro apps like a pig (it's a 2 ghz celeron)..."

Laptops really aren't for gaming. Hence the crumy celeron processor. Also, what graphics card(if any) does it have? How fast something runs really depends on your graphics card.

Also, not to be rude or anything, but did you consider that maybe it isn't DBPro that is slow but your code?

"My mom certainly has a computer from about 4 years ago, and it doesn't have a 3d capabilities."

And my brother has a computer that is 4 years old and it can run DBPro apps just fine. So your point is? Cheap, low power computers are sold all of the time and to be perfectly honest, I don't think anyone that plays games has a computer that doesn't have at least a 3d graphics accelerator.

" How many of those Geforce4's that came out were upgrades for Gamers... IE, not my target..."

Huh? The card I cited was a Geforce 256. Not a Geforce 4. The Geforce 256 is way older than the Geforce 4 and has a fraction of the capabilites of that card.

By the way, how do you plan on selling games to people who don't play games? Isn't that really a losing investment?

"Well, that's great for him. But how many people are doing this?"

Probably not many. But even if you had all of the changes you suggested implemented and then some I doubt that the number of people who make projects that big will change. Its not about the capablities of the language, it's about the drive and determination of the coder that gets the job done.

"What's wrong with rocking the boat a little to try to get some positive change?"

Nothing. Just don't be surprised when people rock back.

"At a job I had in 1999/2000 their was a file in the tree that had 18000 lines of code. 1 File, amongst thousands in the tree."

So? That was at a company with no doubt numerous paid coders. This was written by 2 guys, presumably in their spare time. Your comparing apples and oranges here.

"Oh, OK. You know whats not a necessity either? Everything invented after punch cards."

Please. Passing by reference isn't all that big of a deal as having to program by punch cards is.

"You know what, never mind. Enjoy DBPRO. It's all yours."

Why thank you. Don't mind if I do.
Back to top
Profile PM
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 31st Mar 2004 11:14
Link
Quote: "casual gamer with a 3-4 year old computer"

And whats wrong with the 'casual gamer' updating to DX9.0b? Even if the graphics card cant actually handle DX9.0b, DBPro games should still run.

Quote: "we have to target games smaller in scope, that have broad appeal"

Not at all - people like niche and different games.

Quote: "I have a feeling that the language itself cannot support large projects."

We wont know until someone tries...

Quote: "Their is no error handling mechanism."

I e-mailed Mike about this a while ago... He said he'll see what can be done.


The place for all great plug-ins.
XP3000+,1Gb RAM,FX5600,1Mb ADSL,Router,.Net 2003 Pro & me
Back to top
Profile PM Email Website
adr
22
Years of Service
User Offline
Joined: 21st May 2003
Location: Job Centre
Posted: 31st Mar 2004 11:23
Link
Firstly, congrats to RobK "the diplomat"
Secondly, Neophyte - for someone who I consider to be very "on the ball" you do seem to be a little too derisive of iaretony's suggestions.

1. My Dell Inspiron 2500 - a 2-3 year old laptop (800Mhz, intel 815 graphics chipset) can run my games just fine. It started to struggle last night when I introduced about 500 ghosted, fading, textured plains, but that was expected (Trying to make an interesting particle system - looks like I need to change tactics). If you're gonna go old-school, it really is a lucky dip it would seem.

2. The thing that stops DBP supporting large projects are the tools. I certainly wouldn't want to get unhandled compiler errors in a 30,000 line project and I have a sneaking suspicion that could happen. I gave up on one of my first projects because I was getting those annoying "failedToCalculate" errors which don't actually give you a line number. Anyway - ways to fix this? Compiler and Debugger improvements, which are in the pipeline I beleive...

3. I guess there needs to be a halfway house. Using java/delphi style try ... finally would just plain piss me off. It's clunky, illegible and would probably put a dent in DBP's speed. However, building in some protection to what we've got, like returning -1 for load object, would be a good start.

There's my measured, calm and concise argument put forward.

...and the rest is f-l-y
Back to top
Profile PM Website
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 31st Mar 2004 11:37
Link
Yes, error returning or possibly doing a GetLastError style error report system (which must already be implemented actually), would be useful. Wonder if IanM knows how to get hold of the last/current error number ?!


The place for all great plug-ins.
Department Head of keeping it Unreal.
Back to top
Profile PM Email Website
AI666
21
Years of Service
User Offline
Joined: 30th Mar 2004
Location:
Posted: 31st Mar 2004 12:44 Edited at: 31st Mar 2004 19:03
Link
First things first: I think DBpro rocks. My "complaints" should be read as an attempt to be constructive and not as whines. I use DB from the good old classic V1 days, and I'm kind of a DB addict, so don't get me wrong. (once I was an AMOS addict, but that is a different story ).

Putting other problems of DBpro aside, my biggest problem in managing large projects in DBpro is compilation times of large projects. The DBpro project is a one big chunk of code (seperation to different files is for the programmer's sanity, but other than that it is kind of meaningless) and there is no way to break the project's functions apart for seperate compilations. There is no way to go around it Inside the language itself.

For instance: I have my own robust GUI system, created entirely in DBpro. I like my gui, because it has a much more "GAME" related feel, compared to windows based gui systems (like the great blue-gui TPC which I use regularly in my aplications). To include my gui system in a DBpro project, I have to recompile it with the rest of the project every single time I change a small thing in my project, even if it got nothing to do with the GUI. If we take into acount the different parts of a medium/large sized project, it doesn't take to much time into the developement process when compilation times start to get rediculously long. The paradox created is: The more robust your aplication is, as more time passes into development, the more you are satisfied with what you created, and the more your project starts to look like as a finished product, the frustration in handling it (bugs, adding small features, little fixes, small touchups etc.) grows exponentialy (make a small change, press f5, go have some tea and bescuits, come back, exit, change another line of code, press f5 again, get older , pull a hair or two from your head, go for a walk, return, see a compilation error, fix it, press f5, make a long phone call, repeat...)

One good solution to that is the use of DLLs and TPCs created by the developer or a third party (created in C++ etc.) and that is the solution I use, though - that is not the optimal and or simplest solution for the DBpro developer.

I do use that solution (I Create my own DLLs in C++ and use TPCs like the Blue-Gui), but it would make me really delighted if there was some kind of an option to compile parts of a DBpro project seperately (compile user created DBpro functions as a DLL or even as a TPC from inside DBpro would be great, but every other solution would be fine). A feature like that is so crucial for me, that I will not think twice before paying good money for it. As it is now: I find myself programming 80% of my big projects in c++ and the rest in DBpro, and that is kind of a shame (because most of these things can be done in DBpro with much less hassle - and that is really the point of the language).

What do you think?

Cheers,
AI
Back to top
Profile PM Email Website
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Mar 2004 13:01
Link
Well I've made 3 games in DBPro, a full featured soundtracker, and am currently working on an art package and modeller in DBPro. That's besides all the demos, level editors and other tools I've done. It's really easy to come along and critisize DBPro, but when so many other people finish projects you've got to look beyond DBPro's foibles and figure out what the problem really is. Mentioning your 386 piecacrap basically invalidated your argument - DBPro has never pretended to run on low spec machines.

OIE is probably my most in-depth game, the game is only about 8000 lines of code. It all depends on how you work, but that's a fairly advanced engine with a custom terrain system, and a DBPro coded collision system - so it's doing more than most engines have to. I don't know how Andy codes, but 100,000 lines is plain crazy - there's no DBPro project that should need that much coding.


Van-B


The nature of Monkey was irrepressible!.
Back to top
Profile PM Email
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 31st Mar 2004 14:07
Link
Just a note about the minimm spec. DBpro needs minimum of 8MB not 16MB graphix card.
Back to top
Profile PM Email Website
Ron Erickson
Moderator
22
Years of Service
User Offline
Joined: 6th Dec 2002
Location: Pittsburgh, PA, USA
Posted: 31st Mar 2004 14:44
Link
DBpro's minimum requirements directly have to do with DirectX 9's minimum requirements. Take your complaint about that up with Microsoft.

EZrotate!
Tokamak Physics Wrapper!
Back to top
Profile PM Email
the_winch
22
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 31st Mar 2004 16:02
Link
Quote: " Just a note about the minimm spec. DBpro needs minimum of 8MB not 16MB graphix card."


It says 16mb here, the 8mb is I guess for the original version before all the patches and move to Directx 9.
http://darkbasicpro.thegamecreators.com/?f=system_requirements
Back to top
Profile PM Website
zircher
22
Years of Service
User Offline
Joined: 27th Dec 2002
Location: Oklahoma
Posted: 31st Mar 2004 18:16
Link
Quote: "Well then again you do pay top dollar."


[snicker] I guess people have different definitions of top dollar. To me, top dollar software costs thousands and thousands of dollars. I've spent far more on inkjet cartridges and paper than I have on DBP.

You get a lot of bang for your buck with DBP. If I were to charge for my future games, I could easily recoup the expense even on a part time basis.
--
TAZ

Game Beavers
Back to top
Profile PM Email Website
zircher
22
Years of Service
User Offline
Joined: 27th Dec 2002
Location: Oklahoma
Posted: 31st Mar 2004 18:23 Edited at: 31st Mar 2004 18:26
Link
Quote: "100,000 lines is plain crazy - there's no DBPro project that should need that much coding."


I don't know the details, but I can see it happening. (Especially if you're heavy into comments/internal documentation, error trapping, or storing data internally.)

VirMin is essentially a chat program with 3D toys and it is over 3,000 lines. If I were to add AI, an online editor, etc., I can visualize it going over 10K and I consider that a simple application.

My next big project is going to be a turn based tactical combat game with the ability to be easily scripted to make mods. I fully expect that to be over 10K lines of code and comments.
--
TAZ

Game Beavers
Back to top
Profile PM Email Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 31st Mar 2004 20:39
Link
@Adr

"Secondly, Neophyte - for someone who I consider to be very "on the ball" you do seem to be a little too derisive of iaretony's suggestions."

Sorry. Its just that I've been arguing non-stop for about a week now and that does tend to leave me on a little bit of a hair trigger.

@AI666

Yeah, compile times can get excessive for large projects. I think your idea of allowing DBPro to compile DBPro DLLs would be pretty good. After all, the DLL file format is identical to the Windows PE file format so it would be a snap to implement DLLs in DBPro. The only difficult part would be generating the string tables which itself probably wouldn't be too hard.
Back to top
Profile PM
DMXtra
22
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 4th Apr 2004 13:27
Link
Keep in mind that some of these "arguments" about weak points of DBPro will be addressed in the future.

Just as Upgrade 6 will solve a lot of issues and introduce new features that have been requested for a long time, it will not solve all problems, but as TGC works on DBPro this will be issues that will be solved probably some time this year.

You have to understand one thing, DBPro is a work in progress as long as its going to be supported. This doesn't mean anyone is going to drop it, but I say this because I don't want to use the term "forever". Basically as technology changes and new ideas emerge so does DBPro. As bugs are fixed and new features released that allow more flexiblity or new technologies to be accessed.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Back to top
Profile PM
Catalyst
21
Years of Service
User Offline
Joined: 6th Sep 2003
Location:
Posted: 4th Apr 2004 13:55
Link
I don't feel like reading all of these posts so I might repeat something that's already been said, but there was a lot said in the early posts about the oh so terribly steep requirements of DBPro. I've had several test programs that had AI,very high poly counts,max lights,and some other random stuff. I've run them on an AMD 2600+ with a Radeon 9800 Pro. I've run them on a AMD 1Ghz with a GeForce 2. In fact, I've run them on a 2Ghz Celeron with integrated graphics. Ran just fine on all of them, never went below playable framerates. In fact, I could build a computer for $300 that would run this stuff easily, very reasonable I would say. As far as DBPro requiring DirectX 9, does anyone else find it funny when people complain about requiring something that's free to download and should be downloaded even if you're not using this software?
Back to top
Profile PM
flibX0r
22
Years of Service
User Offline
Joined: 14th Feb 2003
Location: Western Australia
Posted: 4th Apr 2004 15:19
Link
This whole section is eminent of what i have seen over and over again in these forums. People not understanding what DBPro is.

DBPro is no for 4 year old computers. Thats what DBC is for. I'm running a p3 600Mhz and a GeForce MX 440, and i get decent frame rates.

A DBPro program will undoubtably have less lines of code. We don't have to initilize DirectX ourselves or anything like that. We can load an image with command.

If you need to pass types and such, why don't you learn C++, and use IanMs interface library.

Seriously, stop yer bitching, n00b.

Current Project: Interactive DBPro Showcase Example
Project Status: Game Engine 90%
http://www.w3th.tk <-- Soon to have some content
Back to top
Profile PM Email Website
Mentor
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 4th Apr 2004 16:11
Link
the original post was a valid comment IMO, I R Tony has a point, requiring dx9.0b, 8mb video ram and 3d acceleration to run "hello world" is just a bit over the top, out of 5 people I know who are in any way "into" computers only one can run anything I write in DB, and thats cos I gave him an old Gf4MX video card, that sort of built in "eliteism" just has to limit the market for DB games, has anyone tried telling their customers to "get a decent computer" when they ask why the specs are so high for a simple game, you won`t find that in any chapter of "how to make friends and influence people"

Having said that, and allowing that IR has a point as regards the current software situation, DB is very future oriented, with the inclusion of stuff like shaders and bsp especialy, I think you have to look at it more as the programming language for the future series of PC`s (ie:from this year onwards) rather than one aimed at the older generation of machines, if you want to write stuff for older machines then you can always use DIV or one of the freeware BASIC compilers for that, nobody forces you to use DB, you can find MS Basic on the win 98 cd in the "old" folder IIRC, all you need is a freeware compiler to compile the source file and you can make your own text based games with that.

Mentor.

PC1: P4 hyperthreading 3ghz, 1gig mem, 2x160gig hd`s, ATI radeon 9800 pro gfx, 6 way surround sound, PC2: AMD 1.2ghz, 512mb ram, FX5200 ultra gfx, stereo 16 bit soundblaster, ups.
Back to top
Profile PM
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 4th Apr 2004 16:23
Link
Quote: "requiring dx9.0b, 8mb video ram and 3d acceleration to run "hello world" is just a bit over the top"

Why ? You need to set up at least 1 video buffer (two or more if there is enough memory). How else are you going to print text ? Use a DOS video mode (which would cause problems on XP machines) ?

Quote: "anyone tried telling their customers to "get a decent computer""

I'm always telling customers where I work to get a new computer - we dont offically support any OS before Windows 2000 for our programs. I've got no problem saying the same thing for DBPro programs. After all, if a computer cant handle DBPro, it probably wont be able to play the latest games anyway.


The place for all great plug-ins.
Keeping it Unreal since 2004
Back to top
Profile PM Email Website
DMXtra
22
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 5th Apr 2004 11:53
Link
If people want to run FAR CRY, DOOM III, Half Life 2, UT 2004, Tomb Raider(new version for the PC), Halo for the PC, etc. Then they are going to have to have a decent video card thats going to cut the mustard.

If they don't have those cards, then they can't play the games, its pretty much that simple. If they don't play modern or semi modern games on their PC, then they probably either don't play games at all or play the games they want on consoles.

Honestly, I don't understand the problem. The people using computers falls under four different types of people.

o People who hardly use computers (mainly for email or once in awhile for MSWORD). These people NEVER play games on their computer

o People who use computers a little more (email, some websurfing, playing web games or windows games). These people might play games that you don't have to install like web type games using Java or Shockwave (yahoo type games) or play Windows built in games like solitare.

o People that are into games but don't have the very latest hardware on PC's, but usually have good enough hardware to play the latest games (maybe not with all effects on). We might call these users casual users and will most likely upgrade or have already upgraded to Direct X 9

o Hard core users are users that have the very latest hardware upgrade and these users buy all of the latest games and have installed Direct X 9 when it became available.

If you are making a game using DBPro, the last two is what you should be interested in getting, if you are not, then you should be using something else.

Like I also said the first two are going to be hard pressed to even look at your game because they may not have the understanding of how downloading and installing and uninstalling a game even works, even if they are interested in playing it.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Back to top
Profile PM
Username Goes Here
User Deleted
Posted: 5th Apr 2004 15:33 Edited at: 5th Apr 2004 15:33
Link
You guys may be true about the people who always play the newest games. They for sure have the newest hardware.

But a lot of people that buy games from the shareware market like puzzle games and stuff that a lot of independent developers create, don't run high end machines. And these people don't wanna deal with stuff like getting the newest graca driver every other week. Most of them never downloaded a patch for the OS I think.

For this market DBPro requirements are to high. That's for sure. But for that I would use a different tool to create games with
Back to top
Profile PM
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 5th Apr 2004 15:56
Link
Quote: "Most of them never downloaded a patch for the OS I think"

Which would mean their computers wont run properly anyway. Would could mean all sorts of technical problems.

Quote: "For this market DBPro requirements are to high. That's for sure."

No, cant agree there.


The place for all great plug-ins.
Keeping it Unreal since 2004
Back to top
Profile PM Email Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 5th Apr 2004 22:57
Link
@MikeHart

"For this market DBPro requirements are to high. That's for sure."

How? Didn't I post a link to a graphics card that met DBPro's requirements and was over 4 years old? And it had twice the amount of required video ram. I seriously don't think the requirements are that high at all. I'd like to see what people consider this target market's standard spec is.
Back to top
Profile PM
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 5th Apr 2004 23:06 Edited at: 5th Apr 2004 23:07
Link
Quote: "How? Didn't I post a link to a graphics card that met DBPro's requirements and was over 4 years old?"


It was cutting-edge over 4 years ago IIRC. What you have to remember is that a lot of PCs which are now say, only 2 years old, have specifications which would have been in-line with a cutting-edge PC 5 years ago. Very few new PCs have half-decent graphics cards.

My college has PCs new only last year, but I can't run DBPro apps on them as the graphics cards (ATI Rage) won't support DX9b.

To be fair though, DBPro has never been aimed at those people. If you want something which has fewer new features, but which runs better on older PCs then DBPro is not for you.

BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games. - Plus URL download, win dialogs.
Over 140 new commands
Back to top
Profile PM Email Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 5th Apr 2004 23:57
Link
@RobK

"What you have to remember is that a lot of PCs which are now say, only 2 years old, have specifications which would have been in-line with a cutting-edge PC 5 years ago."

Yes, that kindof was my point. Though I wouldn't go as far as to say 5 years ago, I think most modern PC users can easily meet the requirements for DBPro. The hardware has filtered into the mainstream enough that to claim DBPro's requirements are high is bit absurd. The only real problem is DirectX 9, but that is easily dealt with by including it in with the installation CD.

"Very few new PCs have half-decent graphics cards. "

I'll have to disagree here. A lot of new PCs come with the cheap Geforce 4 mx. Even though it is a piece of crap, it easily meets DBPro's requirements. Even integrated graphics chipsets can meet DBPro's requirements now. Here is an article from September 3, 2003 detailing some of the latest integrated graphics chipsets.
http://www.tomshardware.com/graphic/20030903/
Everyone of those chips can have 16mb of vid mem(taken from system mem).
There is even an integrated graphics chipset that can run pixel shaders. Here is a news snippet from June 23, 2003:
http://www.cpuplanet.com/news/article.php/2226021
These are all from last year and are filtering there way into the mainstream. I think it is safe to say that in a few months time we should be seeing cheap mainstream PCs coming out with these chips.

"My college has PCs new only last year, but I can't run DBPro apps on them as the graphics cards (ATI Rage) won't support DX9b."

I'm not surprised. I don't think your college's administration wants people playing games on their comps. So, obviously, they are going to skimp on the graphics cards and get DX 6 class cards if any.
Back to top
Profile PM
kidsa
21
Years of Service
User Offline
Joined: 8th Dec 2003
Location: MA,usa
Posted: 6th Apr 2004 00:28
Link
Quote: "Well I've made 3 games in DBPro, a full featured soundtracker, and am currently working on an art package and modeller in DBPro. That's besides all the demos, level editors and other tools I've done. It's really easy to come along and critisize DBPro, but when so many other people finish projects you've got to look beyond DBPro's foibles and figure out what the problem really is. Mentioning your 386 piecacrap basically invalidated your argument - DBPro has never pretended to run on low spec machines.
"

van b youve made a level editor? can you post the link?

i used to be kidsa the random one i guess im not as random anymore.

any language used by me will be dbpro(saves me a lot of typing)
Back to top
Profile PM Email
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 6th Apr 2004 01:23 Edited at: 6th Apr 2004 01:32
Link
Quote: "I think your idea of allowing DBPro to compile DBPro DLLs would be pretty good. After all, the DLL file format is identical to the Windows PE file format so it would be a snap to implement DLLs in DBPro. The only difficult part would be generating the string tables which itself probably wouldn't be too hard."

Not quite. The way DBpro generates executables doesn't allow this 'cause the executables are not created from the scratch. Basically a DBpro exe is an application that contains the compiled machine and, when launched, extracts/strips this code (as well as the DLLs) to the temp folder, loads it back and finally calls it. With this method you can't create DLLs easily because for example you do need a proper export table and a few flags to be set correctly. It's not impossible but it's certainly not a snap.

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
Back to top
Profile PM
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 6th Apr 2004 01:28 Edited at: 6th Apr 2004 01:31
Link
Quote: "I'm not surprised. I don't think your college's administration wants people playing games on their comps. So, obviously, they are going to skimp on the graphics cards and get DX 6 class cards if any."


The point is though that it isn't just about games. DBPro is designed as a games creating language, I'm happy with that. However many people have tried to use DBPro for other uses, undeniably, the ability to have 3D graphics would be very useful in many educational and other related purposes. I think there would be a market for a version of Pro which could run on lower spec machines (TGC could buy out Blitz )

Also, in my experience, although Pro will run on lower spec machines, performance tails off rapidly. I would say that with high spec hardware, Pro easily outperforms competitors, but not so on lesser hardware, which, it could be argued, constitute the internals of most people's PCs.

(Edit, you can tell I had just finished watching Yes! Minister before I wrote that ^^)

BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games. - Plus URL download, win dialogs.
Over 140 new commands
Back to top
Profile PM Email Website
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 6th Apr 2004 01:35
Link
The problem is for lower spec machine, you would then have to use an older version of DX and lose all the nice bits in DX9...


The place for all great plug-ins.
Keeping it Unreal since 2004
Back to top
Profile PM Email Website
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 6th Apr 2004 01:53
Link
True.

Its not the case, unless the engine was designed in such a way that the renderer could easily be changed as necessary.

However this would only have been possible if all the DX-related stuff was contained in a seperate DLL. Then you could have had DX8 and DX9 versions, all exporting the same functions so that it wouldn't matter to the other parts of the engine which DX version was being use. At least, I think this would have been possible if you were doing an engine from scratch - DX experts feel free to correct me.

BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games. - Plus URL download, win dialogs.
Over 140 new commands
Back to top
Profile PM Email Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 6th Apr 2004 04:06
Link
@empty

"Basically a DBpro exe is an application that contains the compiled machine and, when launched, extracts/strips this code (as well as the DLLs) to the temp folder, loads it back and finally calls it."

Hmmm. So basically what you are saying is that the compiler has some sort of app template it stores and when it creates an executable it packs the machine code and necessary dlls in the resource section of this app template. Then when it launches it strips them out into the temp folder, loads them back into memory and starts executing the now loaded instructions. Correct?

That seems like a strange way of going about creating an executable.

" With this method you can't create DLLs easily because for example you do need a proper export table and a few flags to be set correctly. It's not impossible but it's certainly not a snap."

The flags could easily be dealt with by pre-setting them in the stored template file. The export table could be a little trickier but it can't be that hard. I've been looking over the format of the PE executable for the last few months and it isn't too complex. But judging by what you said, it sounds like lee doesn't know the PE file format and is instead relying heavily on the IMAGEHLP.dll(or something similar) and a template file to create executables.

In that case, I guess it certainly wouldn't be a snap.

@RobK

"The point is though that it isn't just about games. DBPro is designed as a games creating language, I'm happy with that. However many people have tried to use DBPro for other uses, undeniably, the ability to have 3D graphics would be very useful in many educational and other related purposes. "

The problem though is its a game creation language through and through. Other people have wanted to use it for other things that it just wasn't built for but I don't think that should count. I don't consider using something for purposes that it wasn't designed for a proper argument against its specifications. It was designed for building modern games and for that purpose its spec is just right.

"I think there would be a market for a version of Pro which could run on lower spec machines (TGC could buy out Blitz )"

Or sell DB classic.

"Also, in my experience, although Pro will run on lower spec machines, performance tails off rapidly."

As would be expected.

"I would say that with high spec hardware, Pro easily outperforms competitors, but not so on lesser hardware, which, it could be argued, constitute the internals of most people's PCs."

It could be argued, but I doubt very well. This issue has been brought up many times and still I just haven't seen any compelling evidence to believe that DBPro's spec is too high. If you were using DBPro for something that it wasn't designed for(non-game apps) I'm sure you could come up with a situation where it just isn't adequate. However, that would kind of defeat the point as DBPro has always been marketed and designed as a modern game creation language. And for that purpose, I think it could be argued quite effectively, its spec is justified.
Back to top
Profile PM
Black Hydra II
21
Years of Service
User Offline
Joined: 26th Nov 2003
Location:
Posted: 6th Apr 2004 06:00
Link
Funny, my computer is five years old and I can run every game ever made with DBPro...

"Damn had to remake account!" direct quotation from previous account.
Back to top
Profile PM
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 6th Apr 2004 11:16
Link
Quote: "Hmmm. So basically what you are saying is that the compiler has some sort of app template it stores and when it creates an executable it packs the machine code and necessary dlls in the resource section of this app template. Then when it launches it strips them out into the temp folder, loads them back into memory and starts executing the now loaded instructions. Correct?
"

Yes, that's correct. Except that data isn't stored in the resource section but simply appended to the exe.

Quote: "That seems like a strange way of going about creating an executable."

Blitz uses a similar (not quite the same) method.

Quote: "The flags could easily be dealt with by pre-setting them in the stored template file. The export table could be a little trickier but it can't be that hard. I've been looking over the format of the PE executable for the last few months and it isn't too complex. But judging by what you said, it sounds like lee doesn't know the PE file format and is instead relying heavily on the IMAGEHLP.dll(or something similar) and a template file to create executables."

That's right the flags are no big problem. But patching an export table of or creating a new table in an existing file isn't that easy.

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
Back to top
Profile PM
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 6th Apr 2004 16:48 Edited at: 6th Apr 2004 17:03
Link
Quote: "It could be argued, but I doubt very well"


My top spec PC (test app rotating 100 low poly models):

DBPro: 160FPS
Blitz: 100FPS

Low spec (2001) PC:

DBPro: 20FPS
Blitz: 35FPS

Make what you will out of that. Looking at the DBDN discussion, DBPro's 3D engine is geared to high performance on modern cards - for example by pushing as much data to the card at once as possible. There is nothing TGC can really do about this as far as I can see, they have to choose a system which supports their target audience, but I can understand why some people find performance too low.

Anyhow, the way which exes are created are certainly odd. Seems like Lee is making life harder for himself.

I noticed that in DBProCore.dll, there are a whole load of functions (at least 20) with names like:

CastLtoF
CastWtoB
CastFtoL

Does this mean that DBPro has to call a DLL function every time it needs to typecast a variable? Or are these legacy functions?

BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games. - Plus URL download, win dialogs.
Over 140 new commands
Back to top
Profile PM Email Website
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 6th Apr 2004 18:45
Link
Quote: "Anyhow, the way which exes are created are certainly odd. Seems like Lee is making life harder for himself.
"


Nah, personally it seems easier building the stub and then just calling your dll functions..


Quote: "I noticed that in DBProCore.dll, there are a whole load of functions (at least 20) with names like:
CastLtoF
CastWtoB
CastFtoL
Does this mean that DBPro has to call a DLL function every time it needs to typecast a variable? Or are these legacy functions?
"


Originally yes, the first editions of the compiler (those very early alphas) just seemed to replace the byte code / jump table base intreperter with a dump of function calls. This was brutal on the cache, and early Dbpro alphas were actually slower than Db classic. Their prolly still used in some cases where hand optimizing isn't convenient, but the bulk of that core operation stuff should now be pure machine code.

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Back to top
Profile PM Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 7th Apr 2004 07:40
Link
@empty

"Yes, that's correct. Except that data isn't stored in the resource section but simply appended to the exe."

I don't think that is possible. I think the windows loader would complain if you did that. The resource section can contain anything you throw in it and you can use the WinAPI to easily extract what you want out of it so I'm pretty sure that that is where he is storing this stuff if he is storing it in the .exe at all.

"Blitz uses a similar (not quite the same) method."

What method do they use?

"But patching an export table of or creating a new table in an existing file isn't that easy."

It isn't too hard either. I've looked over the info I've got and basically its just the export directory table which is 40 bytes in size with three arrays after it whose size are defined in the table. There's also a bunch of null-terminated strings after that for the function names as well. Nothing to hard. It's not like the resource section where you have to sort through a binary tree.

@RobK

"My top spec PC (test app rotating 100 low poly models):

DBPro: 160FPS
Blitz: 100FPS

Low spec (2001) PC:

DBPro: 20FPS
Blitz: 35FPS"

What no exact specs?

"Make what you will out of that."

I'm not sure what to make out of it. I don't know what the precise specs for those machines are. Nor do I know what you consider "low-poly" or whether the models were stripified or not. Also, rotating 100 models at once is quite a bit of work.

Anyway, this probably doesn't change anything. Some people will find DBPro's specs to be too high regardless of what they are. And some will be able to use DBPro apps on 5 year old comps. I don't think this debate will die down anytime soon.

"Anyhow, the way which exes are created are certainly odd. Seems like Lee is making life harder for himself."

I think it evolved out of the fact that he was on a deadline and didn't have the time to figuare out the format himself. I've been researching the format myself and the info isn't exactly easy to find. Its taken me some months to find decent docs on this stuff, mostly by accident, and it still really isn't clear unless you get a Hex viewer and walk though the thing step by step.

"I noticed that in DBProCore.dll, there are a whole load of functions (at least 20) with names like:

CastLtoF
CastWtoB
CastFtoL"

Yikes! I think I'll have to check that out later when I get the time.

@UWDesign

"Nah, personally it seems easier building the stub and then just calling your dll functions.."

Easier certainly, but I wouldn't say the most peformance effecient method.

On another note, how is playbasic coming along? I'm not too far along with my compiler but I think I'll be hitting a major milestone soon once I get the .lib format down and a rudementary linker implemented.
Back to top
Profile PM
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 7th Apr 2004 10:29
Link
Neo:

Yeah Pb's going well.. Just taking it easy now..

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Back to top
Profile PM Website
Teh Go0rfmeister
21
Years of Service
User Offline
Joined: 17th Aug 2003
Location:
Posted: 7th Apr 2004 11:16
Link
nag nag nag.

why dont you go and find something better than DBP then?

ffs i have 3 enemies:

freinds of the earth
femenists
complainers.

http://www.tinnedhead.tk under re-construction.
Back to top
Profile PM Website
Powersoft
21
Years of Service
User Offline
Joined: 1st Aug 2003
Location: United Kingdom
Posted: 7th Apr 2004 12:05
Link
With half decent computers becoming cheaper you dont have to worry as much about the spec. as the new computers people are getting a better

Just to add to the confusion.
Look at my avatar
Back to top
Profile PM Email Website
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 7th Apr 2004 13:06 Edited at: 7th Apr 2004 13:22
Link
Quote: "I don't think that is possible. I think the windows loader would complain if you did that. The resource section can contain anything you throw in it and you can use the WinAPI to easily extract what you want out of it so I'm pretty sure that that is where he is storing this stuff if he is storing it in the .exe at all."

The loader won't complain. It is possible and widely used (Even I used it for a screensaver maker). It has one advantage over a resource section: The data stored in there, isn't mapped into the memory by the loader.

Quote: "
"Blitz uses a similar (not quite the same) method."
What method do they use?
"

The runtime library is exported by the "template" exe and the machine code data is stored in the resource section. It doesn't strip the code to the disk and loads it again, but moves it within the memory.


Quote: "It isn't too hard either. I've looked over the info I've got and basically its just the export directory table which is 40 bytes in size with three arrays after it whose size are defined in the table. There's also a bunch of null-terminated strings after that for the function names as well. Nothing to hard. It's not like the resource section where you have to sort through a binary tree.
"

Yes, you have an export table directory containing the the numbers and addresses of the exported functions, of their names and their ordinals. In order to calculate the RVAs and update the optional header you'd need a nearly complete linker. That renders the idea of having a template file useless and it would make more sense to create executables the ordinary way.

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
Back to top
Profile PM
flibX0r
22
Years of Service
User Offline
Joined: 14th Feb 2003
Location: Western Australia
Posted: 7th Apr 2004 13:49
Link
I'm running a p3 650MHz system

I have upgraded 3 things in the last 2 years. The graphics card (GeForce MX 440 128Mb ), another hard drive (80Gb Seagate) and Windows XP Pro.

I can run almost any program made in DBPro. The only thing i can't run in anything with pixel shaders, and i run vertex shaders like crap.

I'm upgrading soon though, but not the graphics card. Eh, i'll live with it.


On the other hand (and i have seven ) i go to a place called the Film and Television Institute (FTI) and they do 3d modelling and games there. Cos they're workstation comps, they're running 6 Dual Xeon 2.2 Ghz and 1Gb DDR RAM and a Quadro 4 XGL 750, and 6 Single Xeon 3.0GHz with 1 Gb DDR RAM and a Quadro FX 1000. But they're for hardcore use and rendering for Film and TV (hence, FTI)

But you should really have tried the demo and asked on the foums about it before getting all the software and bitching about it. If you want to make a simple text game or RPG, use DBC. If you want to make something with cool graphics and nice speed, use DBPro.

Current Project: Interactive DBPro Showcase Example
Project Status: Game Engine 90%
http://www.w3th.tk <-- Soon to have some content
Back to top
Profile PM Email Website
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 7th Apr 2004 23:43
Link
@uwdesign

"Yeah Pb's going well.. Just taking it easy now.."

Good to hear.

@empty

" The loader won't complain. It is possible and widely used (Even I used it for a screensaver maker)."

Really? I'll have to look into that. It sounds interesting. One question though: How do you know where to load it from the file?

"It has one advantage over a resource section: The data stored in there, isn't mapped into the memory by the loader."

That's true. I hadn't thought of that.

"The runtime library is exported by the "template" exe and the machine code data is stored in the resource section. It doesn't strip the code to the disk and loads it again, but moves it within the memory."

Similar to what I thought of then.

"In order to calculate the RVAs and update the optional header you'd need a nearly complete linker. That renders the idea of having a template file useless and it would make more sense to create executables the ordinary way."

Not really. I'm pretty sure you could get away with using your own internal format to represent the code in instead of those old COFF object files. That would eliminate a lot of the difficulty and effort in writing a linker. I know. I'm writing one now and having to traverse through this old format isn't exactly pleasant or easy.
It probably is what takes up the most of my time. If I just had to update a few fields I would have been done ages ago. Instead I have to figuare out this strange format with few examples to go by and do relocations of the code.

If I had just one object file to deal with I could do relocations when I generate the code, probably like lee does. In fact, I might not have to do any relocations at all as the whole point of relocations is you don't know where in the final executable this code is going to be. With just one Obj file you know exactly where they are going to be. So with you own internal format and no relocs or groups to merge, writing a linker would be a piece of cake.

Assuming your putting the code into the file and not appending it, you'd need to update the SizeOfCode field, AddressOfEntryPoint, BaseOfCode, SizeOfImage, SizeOfHeaders, NumberOfRVAandSizes, and in the COFF header you'll need to change the NumberOfSections, SizeOfOptionalHeader, and Characteristics(but only if you are making a DLL. Otherwise you could just leave it as indicating an executable). The only hard part after that is making sure the code fits into the sections and is aligned. Oh, and you'd have to fill out the export table too if you were making a DLL.

All of this would be a lot easier with a template to work from where when you loaded it into memory you know exactly where to look for the majority of those fields. The rest of which can be created and appended to the template.

And this is all assuming you are going the long route and injecting the code in and not appending it. I'm pretty sure you could get away with appending the code for a dll in the resource section. Correct me if I'm wrong, I haven't looked into DLLs that much, but I could have sworn there was some sort of main function or something that executed when it was loaded into memory by an .exe. I'm pretty sure that you could put some standard code in there to load in the compiled code from the resource section. If there isn't you could always have the compiler create one and call that function every time a DBPro dll is loaded.

You could easily get away with a template file then as the only thing you would have to update is the resource section(which could be appended to the end of the .exe) and the SizeOfImage field. You'd than need to deal with offsets into the loaded code for the functions but that could be handled transparently by the compiler. You could even add this info into the resource section(as it can pretty much hold anything) so other DBPro users can use DBPro dlls(albiet not as easily as regular DLLs).

But, I'm rambling. I need to get back to coding now so I think I'll have to end this post.
Back to top
Profile PM
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 8th Apr 2004 00:09 Edited at: 8th Apr 2004 00:12
Link
Quote: "Really? I'll have to look into that. It sounds interesting. One question though: How do you know where to load it from the file?"

Put the address of your appended data at the end of your exe and read it from there (or if you want your app working with the most common exe compressors, put it somewhere near the end of the file, ie. add some uneeded bytes after the address).


Now comes a very long part

Quote: "Not really. I'm pretty sure you could get away with using your own internal format to represent the code in instead of those old COFF object files. That would eliminate a lot of the difficulty and effort in writing a linker. I know. I'm writing one now and having to traverse through this old format isn't exactly pleasant or easy."

Yeah I know, I've been there.

Quote: "If I had just one object file to deal with I could do relocations when I generate the code, probably like lee does. In fact, I might not have to do any relocations at all as the whole point of relocations is you don't know where in the final executable this code is going to be. With just one Obj file you know exactly where they are going to be. So with you own internal format and no relocs or groups to merge, writing a linker would be a piece of cake."

Well, neither DBpro nor Blitz need to calculate any relocations during compile time, that's the advantage of the template method. All you need to do is map the compiled machine code to an allocated memory, mark this area as executable, and there you go.
My original point was, with the current compilation method, creating a DLL is not a snap.


Quote: "And this is all assuming you are going the long route and injecting the code in and not appending it. I'm pretty sure you could get away with appending the code for a dll in the resource section. Correct me if I'm wrong, I haven't looked into DLLs that much, but I could have sworn there was some sort of main function or something that executed when it was loaded into memory by an .exe. I'm pretty sure that you could put some standard code in there to load in the compiled code from the resource section. If there isn't you could always have the compiler create one and call that function every time a DBPro dll is loaded."

Yes there is a DLLMain routine that is called when the DLL is loaded, but you can't just map the DLL functions and call them. One of the reasons has something to do with the import table. It is possible to load a DLL that is stored somewhere in the exe, but it needs a lot more than that. (Been there too )

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
Back to top
Profile PM
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 8th Apr 2004 07:23
Link
@empty

"Yeah I know, I've been there."

What were you coding when you had to deal with COFF? Were you writing a linker/compiler like I am by chance?

"My original point was, with the current compilation method, creating a DLL is not a snap."

I suppose we have different idea's of what a "snap" would be. *shrugs* I'm afraid we'll have to agree to disagree on this one.

"(Been there too )"

Now you've got my curiousity going. What exactly were you working on that required these things, if you don't mind me asking?
Back to top
Profile PM
empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 8th Apr 2004 11:43 Edited at: 8th Apr 2004 11:44
Link
Quote: "I suppose we have different idea's of what a "snap" would be. *shrugs* I'm afraid we'll have to agree to disagree on this one."

Hmmm, ok.


Quote: "Now you've got my curiousity going. What exactly were you working on that required these things, if you don't mind me asking? "

I've been writing a linker, which pretty much works but isn't complete and currently only the resource linking part is used in PlayBasic. The DLL loader is in the same state (although it still has one serious bug). At the moment I have to focus on other things of the project, so I can't work on these parts.

Me, I'll sit and write this love song as I all too seldom do
build a little fire this midnight. It's good to be back home with you.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-06-05 19:01:41
Your offset time is: 2025-06-05 19:01:41