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 / How do you guys survive when you have more than 23000 lines of code?

Author
Message
Mnemonix
22
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: Skaro
Posted: 14th Sep 2004 01:40
Doom3 was around 20 lines i think. Written in dbc too. By me!!!!eleven

The 3d chat is coming...
In the meantime, come in the IRC. Ask me for details!!.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Sep 2004 01:43
Quote: "There were over 500,000 lines of script code written and over 50,000 image files generated in the process of creating all of the graphical interfaces, computer screens and displays throughout doom3."
- page 11 : doom 3 manual

sorry but the Executable for Doom3 is 3.66MB (Doom3Ded.exe) from the upcomming 1.05 Release.
so your talking in the region of atleast 3 million lines of code, if not more; what's more is it is self generating, something which takes a hell of alot to do to make it work right.

As for that large a DBP Project, actually nope... never had it reach that much yet.
From what i've seen from compile times, i hope to hell it never does as i build often meaning 3-4minutes for a single build is gonna slow down development, until there is a way to have seperate and more modular development within dbp at any rate.

This said, the way I code isn't optimised; dbp optimisation means pure procedural coding, the fps difference is just remarkable but you end up with so many lines of code you've got to weigh up the benifit to cost.
Personally I code trying to make everything relay and reuse as much code as possible, so making sure a function has say an extra parameter as a boolean so you can switch it's operation rather than having 2.

I'll see about posting some examples of what i mean once i get home, as often you'll find the quickest way to compile and for game speed is to make everything longer and simpler.
For project neatness however you'd want things to be function controlled and spread out into small code sections.


David T
Retired Moderator
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 14th Sep 2004 01:44
I wonder how many lines DBP is

Get 15 new commands, all the date / time commands left out of DBPro for free!
DOWNLOAD PLUGINS HERE: http://www.davidtattersall.me.uk/ and select "DarkBasic"
Peter H
21
Years of Service
User Offline
Joined: 20th Feb 2004
Location: Witness Protection Program
Posted: 14th Sep 2004 02:09 Edited at: 14th Sep 2004 02:21
[edit] oops didn't realize this thread had gone over one page
what i said in response to the last post of teh first page...
Quote: "the graphics are because of the artist not because of the language

PROGRAMMING LANGUAGES DO NOT CREATE GRAPHICS!!!
(except for shaders...)



anyway awesome graphics in that game you have there bullseye
"



@raven-
Quote: "dbp optimisation means pure procedural coding"

so are you saying to cut out all the functions and gosubs like this?(except on a much larger scale...)

function oriented code-


not-so-function oriented code-


this would be something i would do AFTER i was done coding...so i would get my project working perfectly(or close) then copy and paste functions into the places where they are used....

but with functions that had parameters then i guess you would just have to do this...





anyway ignore this post...i'm just thinking it all out...

"We make the worst games in the universe."

Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Sep 2004 03:08
sort of peter, just more means long handing.
using a do..loop is also bad for speed, you might not notice this on small loops, but it is.


Peter H
21
Years of Service
User Offline
Joined: 20th Feb 2004
Location: Witness Protection Program
Posted: 14th Sep 2004 03:13
i hadn't noticed that...for simple games(as in every game i've made so far...) i use Do loop for the main code...

are do-while or repeat-until loops faster?
I.E.
repeat

until escapekey()=1

"We make the worst games in the universe."

Gamefreak
20
Years of Service
User Offline
Joined: 20th Jun 2004
Location: Cyberspace
Posted: 14th Sep 2004 06:48
Bulleyes, nice models! How do you make those (and the textures)?????
Rknight
21
Years of Service
User Offline
Joined: 25th Sep 2003
Location: NJ
Posted: 14th Sep 2004 10:16
If you're going for a CPU upgrade, consider a motherboard upgrade and don't stint on the motherboard. What motherboard you use can be more influence than what CPU. Try Tom's Hardware guide or some similar site to make sure you get a decent one.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Sep 2004 20:21
nope what my brother has discovered is if you purely stick to code which uses labels, goto and if statements you can increase speed almost 4-5x ... he discovered this in DB Standard but it also works in Professional too.

I'm guessing the way that DB does tasks like that mean that it jumps back to the main loop then calls the statment again rather than doing it in-line like it should be.

so if your doing it for small operations and calling it only a few times your not going to notice really, but when you call it more and more it is probably filling the stack at which point will lag the program while your cpu catches up.
(so this would no doubt affects Pentiums more with thier 4 stacks to AMDs 7)

i used to have a platformer game around here which i thought was pretty cool, but i had it running at a reasonable 24fps... he got ahold of it and got it upto 90fps.


Philip
21
Years of Service
User Offline
Joined: 15th Jun 2003
Location: United Kingdom
Posted: 14th Sep 2004 22:21
I've not noticed any problem with speed with DBPro at all.

This might be due to the relatively high specs of my system.

Philip

What do you mean, bears aren't supposed to wear hats and a tie? P3.2ghz / 1 gig / GeForce FX 5900 128meg / WinXP home
the_winch
22
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 15th Sep 2004 02:40
It's been discussed may times before. If I remember correctly it is due to the excessive ammount of windows event checks dbpro does every loop as well as on syncs. The newer versions are susposed to have removed a lot of the checking speeding it up.

There is a bug report discussing it here as well as numerious other threads on the subject.
http://forum.thegamecreators.com/?m=forum_view&t=26633&b=15


it's cool to hate
Bulleyes
22
Years of Service
User Offline
Joined: 3rd Nov 2002
Location: Cyberjaya, Malaysia
Posted: 15th Sep 2004 13:07
The new one? You mean Upgrade 5.6?

Bad Nose Entertainment - Where games are forged from the flames of talent and passion.

http://www.badnose.com/
The dude guy
20
Years of Service
User Offline
Joined: 3rd Aug 2004
Location: In the streets of sasatuin
Posted: 16th Sep 2004 08:55
@ Bullseye: THOSE GRAPHICS ARE AWESOME!!!!!!!!!!!!!!!!!!!

Here's my forums www.andrewtamalunas.proboards28.com . Please join!
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 16th Sep 2004 09:15 Edited at: 16th Sep 2004 09:18
Quote: "what's more is it is self generating"


Err... no. Whilst John Carmack is a very talented coder I don't think he would have included a compiler in the Doom 3 exe for the fun of it. Sure Doom 3 has scripted sequences, but this is about as close as it gets.

In addition the Doom 3 exe is likely to get larger rather than smaller by 2MB in a patch.

Doom3Ded is the dedicated server executable.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 16th Sep 2004 09:31
Quote: "Err... no. Whilst John Carmack is a very talented coder I don't think he would have included a compiler in the Doom 3 exe for the fun of it. Sure Doom 3 has scripted sequences, but this is about as close as it gets."


Wrong.
Doom3's Graphics User Interface system uses script structures which Doom3 then takes and SELF-GENERATES the neccessary code and images in order to create the user interface.

Quote: "In addition the Doom 3 exe is likely to get larger rather than smaller by 2MB in a patch."


As for a Compiler inside the .exe... well the Executable has inside it:

a/ Game .exe
b/ Editor .exe
c/ Rad Compiler
d/ Vis Solution Compiler
e/ BSP Compiler

When I noted the .exe size, I was quoting what the PURE .exe size is, not the dedicated .exe ... what's more you can actually command line and start up doom3 using dedicated .exe, however you will not have access to certain things.

there is a reason Doom3 takes up 400MB SwapFile memory, it isn't just so it can bloat itself out.
jesus read the damn quote i posted which you can find in the manual, i even gave out the page number for people to look it up.

Scripted Events are something entirely different.


Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 16th Sep 2004 11:05
Raven,
Valid points, and nice argument, no need to get heated, let's keep this at a discussion level

Jess.


Team EOD :: Programmer/All-Round Nice Guy
Aust. Convention!
Tapewormz
22
Years of Service
User Offline
Joined: 15th Sep 2002
Location: Winnipeg, Mantoba, Canada
Posted: 16th Sep 2004 14:49
Erm...If you have that many lines of code when using DBP...Then your game better be extraordinary. Using DBP saves you hundreds and hundreds of lines of code.

I don't think it's possible that you've made a game with over 25K lines of code.

Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 16th Sep 2004 22:37 Edited at: 16th Sep 2004 22:39
Quote: "Doom3's Graphics User Interface system uses script structures which Doom3 then takes and SELF-GENERATES the neccessary code and images in order to create the user interface."


That sounds highly illogical to me. Can you provide links to more technical information? If Doom can work out how the UI is supposed to behave from a "scripting structure" then why would it need to "self-generate" more code?

Quote: "When I noted the .exe size, I was quoting what the PURE .exe size is, not the dedicated .exe"


I can assure you, the executable Doom3Ded.exe is the dedicated server. The Doom3.exe file is 5.6MB.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 16th Sep 2004 23:53
again no Rob...

Doom3.exe is 6.41MB
Doom3Ded is 3.66MB

You DO NOT get Doom3Ded.exe on standard installation, it is only available via the Beta 1.05 Patch.
Which you can currently download from FilePlanet.

The standard boot-up for Doom3Ded.exe is to simple create a dedicated listening server, however it is not purely for server games. It is capable of running the actual game and is the test version for the Demo .exe as there is no need for the level editing tools within the demo version of the game due out in December (along with the LGPL Quake3 Source)

How the GUI works is very simple and for saying you've worked extensively with Visual C++ and Windows API, your attitude towards what id Software has achieved is quite surprising.

i'll try my best to explain how it works though.

you would have yourself a .gui structure like such:



from that small script structure, what happens is Doom3 will take that and then create a menu for you based on your script... just like Windows will create Menus/Dialogs from Resource Structures.

you give it the information and it'll generate the necessary code and run it in order for it to work, the way it has been created gives you so much control over how the menus are generated and built.
i do kinda wish Windows UI worked like it actually.


Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 17th Sep 2004 01:13
Quote: " again no Rob...

Doom3.exe is 6.41MB
Doom3Ded is 3.66MB"


That is exactly what I said

Quote: "you give it the information and it'll generate the necessary code and run it in order for it to work, the way it has been created gives you so much control over how the menus are generated and built."


I still have my doubts, but in that case, any "generated code" would not contribute to the line count figure - as it wouldn't affect the compile time for the exe.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Sep 2004 04:17
Quote: "That is exactly what I said "


Erm... just look in the post above mine, that isn't what you said.
This aside the actual EXE itself, pure game not anything extra (which i'm still completely baffled to why the hell it is part of the exe itself) is actually closer to 2.8MB

Quote: "I still have my doubts, but in that case, any "generated code" would not contribute to the line count figure - as it wouldn't affect the compile time for the exe"


Of course it wouldn't, no one said it would. But the code used in ORDER to generate the code (ie the runtime interpreter) happens to be just over 500,000 lines of code *alone*.

that was the orignal point which you seemed to have completely missed.


JeBuS
20
Years of Service
User Offline
Joined: 20th Jul 2004
Location: Undisclosed Location, Dominion of JeBuS
Posted: 17th Sep 2004 04:19
*wonders what all this doom exe size talk has to do with managing DBP projects*


High quality models and graphics, low prices. Graphics for the rest of us.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Sep 2004 04:24
It doesn't Jebus... it is a typical fashion of someone trying to make a dig, and changing the subject in the process.

an original point i was trying to make was that someone believed that Doom3 was something like 3,000 lines of code or something which was just ridiculous.

the number lines of code have nothing to do with how good or bad your projects are either.

for example, Black & White is a mear 20,000 lines of code... however it creates close to 10-50x that while your playing as it scripts itself to adapt around the engine.

personally i do think 23,000 lines for a DBP project though is a little excessive.


empty
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 17th Sep 2004 05:16
More reliable sources talk about 780,000 lines of code for Doom 3. And no, I don't believe it "generates code" on the fly. And if it did it wouldn't take 500,000 lines of code.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 17th Sep 2004 06:33
Raven,

From the example displayed above, which I do _agree_ looks to be nice way to externally build any app's interfaces, let alone Doom3. But from looking at it, there doesn't appear to be anything in that example that would require D3 to generate reams of interface code at run time. It's mostly setting properties with some very simple actions attached. Which could be interpreted at run time easy enough.


On the subject of compilation speed, as excessive as 23K lines of Dbpro code might appear to some, it's difficult to swallow that compilation times of a couple of minutes are acceptable.

It's bemusing to think that since Lee is developing FPSC in Dbpro, which he reportablely broken in various part due to compilation speed himself. So why couldn't he invest a few days (or less) to resolve some of the bottle necks in the compiler. I suspect it's either the using linear searching to ID commands/variables or the string handling is a bit iffy.. Whatever the cause, Imagine the time he could have save himself and user base, with even a 10% or 25% increase. I'd be surprised if it couldn't be boosted 50% or 100% or more.

Kevin Picone
[url]www.underwaredesign.com[/url]
Play Nice! Play Basic - Next generation Basic coming Oct-2004 (V2.21 Out Now)
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Sep 2004 06:33 Edited at: 17th Sep 2004 06:39
Quote: "More reliable sources talk about 780,000 lines of code for Doom 3. And no, I don't believe it "generates code" on the fly. And if it did it wouldn't take 500,000 lines of code."


More reliable than the MANUAL?! o_0

Quote: "From the example displayed above, which I do _agree_ looks to be nice way to externally build any app's interfaces, let alone Doom3. But from looking at it, there doesn't appear to be anything in that example that would require D3 to generate reams of interface code at run time. It's mostly setting properties with some very simple actions attached. Which could be interpreted at run time easy enough."


heh... well it is setting the structure and it could be done as an interpreter, however you have to remember that this controls the PDA which is in-game so you have all the other calculations going on. Not to mention it had to run on the X-Box.

i think it was a speed choice rather than complexity choice, ya know?
it does work from a remarkably small library of images which create thier own zones and everything.
the entire library is just as extensive as Windows API really, as it has windows, tabs, buttons, scroll areas, text areas, header areas, etc...

it is very impressive stuff.


JeBuS
20
Years of Service
User Offline
Joined: 20th Jul 2004
Location: Undisclosed Location, Dominion of JeBuS
Posted: 17th Sep 2004 06:40
*sigh* I tried to get it back onto the right track...

@Raven
One of many things I learned from Master of Orion 3's release was that the manuals can be created well before the game is ever finished, and as such, their information may be dated.

Not saying that is the case with Doom 3, just saying it's possible.

Anyway, can we drop the Doom 3 bickering now, ladies?


High quality models and graphics, low prices. Graphics for the rest of us.
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 17th Sep 2004 06:58 Edited at: 17th Sep 2004 07:00
Quote: " It doesn't Jebus... it is a typical fashion of someone trying to make a dig, and changing the subject in the process."


If you post questionable information don't be surprised when people disagree

Back to DBPro and compile time, as I see it there is a lot of room for improvements in the compiler. Blitz can manage the same amount of code in less than a third of the time, and after Lee has finished work on FPSC (or hopefully during his time working on FPSC), he will be able to make these improvements. It needs to be sorted though. Any full commercial game is likely to be at least 6000 lines long, and even on a fairly fast machine that takes a fair while for the compiler to crunch through.

In addition, I think it would be nice if the DBPro core structure had handles of loaded user-plugins so that you could access them via IanM's lib without him having to add specific code for that TPC to work.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Bulleyes
22
Years of Service
User Offline
Joined: 3rd Nov 2002
Location: Cyberjaya, Malaysia
Posted: 7th Oct 2004 19:16
For those that are still wondering what games am I developing with 23000 lines of code (approaching 30000 fast), check out the WIP forum below,

http://forum.thegamecreators.com/?m=forum_view&t=40483&b=8

Thomas Cheah (Technical Director)
Bad Nose Entertainment - Where games are forged from the flames of talent and passion.
http://www.badnose.com/

Login to post a reply

Server time is: 2025-05-29 17:29:59
Your offset time is: 2025-05-29 17:29:59