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 / How do you code?

Author
Message
Indicium
16
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 18th Jul 2011 16:13
Hey. I'm just wondering how everybody else here writes their programs.

Personally I always feel like I'm making no progress at all because everytime I add a new feature, such as ... I don't know, sidewards camera movement I stop coding, compile and see if it works.

I do this for everything I add or tweak, so if I change the speed of the camera movement, I compile again and see what it's like.

Does anybody else do this? Or how do you test/develop your games and applications?

Indi.

Serial Velocity
16
Years of Service
User Offline
Joined: 24th Aug 2008
Location:
Posted: 18th Jul 2011 16:19 Edited at: 18th Jul 2011 16:26
I'm pretty much the same as you, although once I've coded a console in, I simply use that at runtime to change variables. For example, I'd write "set 0x0EA0EEFF, 300" and use the VC++ debugger to get the memory address of the variable I want to change.

However, it's a good idea to wrap all your logic code, like AI and stuff into scripts powered by Lua or something, so you dont need to recompile your project every time you make a change, but instead simply reload the scripts.

swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 18th Jul 2011 16:26
yep. Pretty much same as you Indicium. I compile a lot. But whenever it's a big change I tend to rework everything, then compile, complain, find typo, and .

swis
No, it's not pokemon.
Joined: Tues Dec 16th 2008
CoffeeGrunt
17
Years of Service
User Offline
Joined: 5th Oct 2007
Location: England
Posted: 18th Jul 2011 16:31
PAGAN_old
19
Years of Service
User Offline
Joined: 28th Jan 2006
Location: Capital of the Evil Empire
Posted: 18th Jul 2011 16:50 Edited at: 18th Jul 2011 16:57
how do i code?

do some coding
LIKE A BOSS!
fix a laptop
LIKE A BOSS
order pizza
LIKE A BOSS
fry a GPU
LIKE A BOSS
rip my hair out
LIKE A BOSS
count my money
LIKE A BOSS
i dont have enough (for a new gpu)
LIke a boss???...
take the heatsink off
LIKE A BOSS
put it in an oven
LIKE A BOSS
set 400
LIKE A BOSS
30 minutes
LIKE A BOSS
take it out
LIKE A BOSS
now it works....

like a boss...

thats how i roll man, thats how i do my codez.

dont hate people who rip you off,cheat and get away with it, learn from them
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 18th Jul 2011 16:53
The more you compile and run, the slower you develop, but the fewer bugs you introduce. Testing relentlessly while you're coding, and keeping a list of known issues is the best way, imo. It's worse on Android though, where the deployment step can take quite a long time.

Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Jul 2011 16:55
It depends on what it is - if it's something familiar, then I've been known to code the whole thing without compiling once. Like a particle system, I've written so many that it's practically automatic for me to add one to a project. Things always need tweaked, but I do tend to hammer in a lot of code, then make tweaks here and there as I go. Usually I try and tweak a few things per compile.

I think though, I'm regressing back to my older style of coding. You'd think that more experience = better planning - but recently all I've found is that more planning = more work = project fail. I want to write a retro game creation system, like SEUCK (kudos to anyone who knows what I'm talking about). And I've started it 4 times, got all obfuscated, and abandoned it. So now, I'm keeping it simple - I'm implimenting the GUI as a map, so the same map editor will be used to design the map editor. Back in the day I would use a grid based GUI quite a lot, and you'd think that was due to inexperience, but I've come to realise that it's more important to be productive than organised. I mean, you don't have to be very organised if your quick . It's like a side project, for working on before I go to sleep, so I want it to be a fun project - when you only want to spend like 30 minutes on something, it's no good to have to tredge through a complex GUI system before you can get to the fun stuff.

Health, Ammo, and bacon and eggs!
thenerd
16
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 18th Jul 2011 16:57
Terribly.

xplosys
19
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 18th Jul 2011 17:16 Edited at: 18th Jul 2011 17:21
Very slowly.

I normally make a short description of the program, it's major parts/forms/etc and the features it will have before I start coding. Then I can check things off as I go. This helps me stay motivated because I can see progress and keeps me on track. Of course, the list will grow and split into sub lists as I code.

I'll jot down a few changes or additions and do them together before I test again. I often find that adding a feature leads to more features (if it's going to do this, then it'll have to have this) so jotting them down kind of helps me see ahead a little. Sometimes I can talk myself right out of a feature by looking ahead to all the other things I'll have to add as well.

Brian.

Zotoaster
20
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 18th Jul 2011 17:25
I take a software engineering approach. I like to think about structure before anything else, and I separate interface from implementation as much as possible.

Generally, I'll write all the important interfaces first, and once that's all neat and tidy, I can allow myself to be slightly messy with the implementation because it's all encapsulated. But yeah, I do the same thing too - write something small, compile, see if it works, and continue. But like VanB, some things I've done so often that I just do them on autopilot.


Quote: "more planning = more work = project fail."

God I agree. It's a catch-22, if you don't plan it enough, you will eventually get caught out, no doubt about it. If you plan too much, suddenly you need a team, and we've all seen how badly that always goes unless people get a salary. It's an art-form in itself to be able to strike the right balance between planning and trusting yourself to do the right thing at the right time, and I think that just comes with experience.

"everyone forgets a semi-colon sometimes." - Phaelax
BlackFox
FPSC Master
17
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 18th Jul 2011 18:02
Quote: "Very slowly."


Or until you see something shiny on the ground and get distracted.

I code quite fine. And I have an advantage- my wife also codes so we can switch off on projects.

- BlackFox
Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 18th Jul 2011 18:30
I plan in my head for a long time when wanting to try a new method or change a particular routine I already have in a major way. Like Van B though if it's something I've done 1000 times already I code till I'm done (from minutes to several hours) then run the program to catch any bugs that may pop up. When it's something I'm unsure of or I'm trying to fix annoying elusive bugs I compile a lot. Once code is down for a routine I save it then I sit there staring at the code and think about how to make it more efficient. I try the thoughts out and if it's better I save again... if it's not good I try something else or just leave it alone. If I mess up the code so badly during the "could I make this better" phase I just reload.

Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 18th Jul 2011 20:07
Quote: "I want to write a retro game creation system, like SEUCK (kudos to anyone who knows what I'm talking about)"

I've been wanting to do the same thing as well. I'm sure I could pull out the amiga and fire SEUCK back up. If I'm lucky I'll even have a disk of my old games.


How I code depends on what I'm doing. Sometimes I'll write a function in a separate program so I can test it independently.

Agreed, planning does make for a longer dev time..... sometimes. If you don't plan your project out, you may find yourself trying to implement things into a system that wasn't initially designed with those functions in mind and you could create major headaches and end up rewriting large amounts of code and spending more time than if you had just planned it out ahead of time.

Non Sequitur M
16
Years of Service
User Offline
Joined: 28th Oct 2008
Location: Where am I!? Where are YOU?
Posted: 18th Jul 2011 20:19
I don't know about you guys, but I code by typing on the keyboard.
Anyway, I do a lot of planning, make a lot of sketches(My artist brain won't let me get away without concept sketches!). Then I start to code it. This is the crucial step. For some reason or other, I either keep coding, or I stop at the first few lines, and decide to move on. Don't ask why. I rarely quit half way through.
crispex
17
Years of Service
User Offline
Joined: 22nd Jun 2007
Location:
Posted: 18th Jul 2011 22:25
I program in a framwork style. Basically what I mean, is I code a basic system that I'm going to use as the backbone for every additional thing I will be doing, that way I can easily implement newer things later. Basically: I make it so I can make new plugins whenever I want.

I just now realized I've had a typo in my signature for the past 3 years.
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 19th Jul 2011 05:26
Depends on the project, but often i'll keep an ideas box for larger projects. Still find keeping a pen and paper near the computer to be one of the most value things. Lets you quickly visualize a problem, then formulate an attack. For smaller stuff though, I tend to write them off the cuff, so whatever happens, happens.

Non Sequitur M
16
Years of Service
User Offline
Joined: 28th Oct 2008
Location: Where am I!? Where are YOU?
Posted: 19th Jul 2011 06:28
Ya know... When I first saw the title of the thread, I thought, "Oh, boy! Another newbie asking us to do their work for them!" Then I saw Indicium had started it, and was like, "WTH!? Indicium!!??" Haha. Then I opened it, and then I realized the title was, "How do you code?" not "How do you code"

Misunderstanding! Haha! Anyway, sorry for the off-topic thought. Carry on, gentlemen.
Agent Dink
21
Years of Service
User Offline
Joined: 30th Mar 2004
Location:
Posted: 19th Jul 2011 06:35
I usually program whole feature, by whole feature. I knock out any and all bugs I can find right then and there. I try not to leave them for later. I compile often, usually as soon as I presume my next bunch of code is working to see my results and make sure everything is in order. Once my project starts hitting a couple hundred lines or I suss out a few features of my program, I go back and start to reorganize it into a clean and neat structure adding source files, moving code, streamlining, and adding comments. Once I feel I've neatened it all up I start that whole process over again.

I think it's fairly effective for me. I'm not one to really think ahead or plan too much when it comes to programming. I don't usually have any groundwork laid out. It kind of builds itself and evolves as I go along.

http://lossofanonymity.wordpress.com
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 19th Jul 2011 10:54 Edited at: 19th Jul 2011 10:54
It depends. My main job has involved a lot of VB and another Unix business basic. The systems I use with these I know very well (16 years working on them everyday well). With these I can code an entire project with possibly only a couple of executions. Sometimes I have no option as it is impossible to execute from the development machine and will only work on the client machine, although in these cases I normally use dummy programs to test things out. These normally go well but are helped by my knowledge and experience of the languages and systems, plus the bulk of the design we put in before hand (I do pretty much everything in the development life cycle) with the client.

On the other hand I'm just getting into programming on the iPhone, Android, and WebOS (Palm), and have little experience there. Ok it's helped by a lot of years of using languages like STOS, AMOS, VB, and DBC/DBP to put together little games, but it's still new and so I am compiling a *lot*. I must have compiled my first iOS app thousands of times before I got it on the store I blame lack of proper design (all in my head, but it's exciting to blast out code when you have a good idea), newness to the language, and robustness of new languages (some things just aren't as stable as a language that's been around for donkeys years).

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Mychal B
14
Years of Service
User Offline
Joined: 21st Jul 2010
Location: Coos bay, rainville
Posted: 19th Jul 2011 11:29 Edited at: 19th Jul 2011 11:30
Im still working on my first project ever in dbpro.... and it's been a year!
Im sure the structure of my program is absolutely horrible, but it works for me. I try to implement a new feature, work out any bugs, then try to optimize, and then organize it where I think is best. Sometimes my code gets so jumbled I'll spend the whole day just trying to reorganize it.

The fastfood zombie killer
Kezzla
16
Years of Service
User Offline
Joined: 21st Aug 2008
Location: Where beer does flow and men chunder
Posted: 19th Jul 2011 13:01
I take a multi-pronged aproach to coding.
I usually make a few seperate study projects to get an idea of how things work and then combine them.

I might create the logic for game flow or ai etc, and experiment with them using a text based program, when it works well I have something to go on.

then i'll compile different elements together and see how the work.

I find the process of making a lot of smaller study programs helps to finalize logic in a way that allows things to be combined easily, rather than doing something one way, putting heaps of work into it and then realizing that to do something else requires massive recoding or inefficient processes.

I just find compatable methods of doing things and string them together as functions or subroutines.

Just like being able to see the next 20 tetris pieces before they come down, things just fit better.


I go for a lot of walks between coding bursts so i can stretch my legs and think about logic, having 1-2 hours to walk home before i can code out an idea allows me to develope the idea further, so when I get home im set to go and blast it out.

I also physically write down conceptual ideas, coding ideas, art ideas

I make todo checklists and mark them off as I go, the unfinished ones make for walk time puzzles.

I guess long story short,

I puzzle over it mentally until I find a certain logical methode of creating something.

then I explore options with coding studies.

then I click the studies together like lego

I compile a lot and add in temporary subroutines to tweak variables to get things behaving well. I write em down on paper and then fix em in the code.

Sometimes I like to use words out of contents
The Slayer
Forum Vice President
15
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 19th Jul 2011 13:36
I tend to compile lots too. Not necessarily to check if it works, but how it feels in the game. Even if I'm certain the code will work, I still compile and play the game, just to make sure it feels the right way. The same goes for when I adjust/redo textures, sound, etc. Just to make sure it all fits like I want, I'd recompile over and over again. Hehehheh.
It's probably also because of the thrill you get when you see your work in action.

Dar13
17
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 19th Jul 2011 18:33 Edited at: 19th Jul 2011 18:34
I create the general framework first(app state engine, modulization, etc) and then as I add the individual modules or features, I'll first test them individually in a test project to make sure the concept works properly.

Then I integrate that code into my framework and modules as best I can.

This process usually works fairly well, except for when I want to expand a feature or module. Then I usually have to throw it all out and start all over again.

EDIT: I compile at least every 100-200 lines of code edited or created.


sprite
19
Years of Service
User Offline
Joined: 22nd Apr 2006
Location:
Posted: 19th Jul 2011 18:55 Edited at: 19th Jul 2011 18:57
My code method

1. Have idea
2. Paper code the problem
3. Look again at the idea again as it maybe be able to do more.
4. write a final version (edits on word)
5. code
6. fix code or logic mistakes.
7. Add into main project
8. repeat 5-6 until the code is working

Do it all again.

I do a bit of coding then drop for rl stuff so I need the documents.

I'll add something later on.
Indicium
16
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 20th Jul 2011 00:16
Quote: "I simply use that at runtime to change variables."

That's a pretty good idea, I'll have to start doing that.

Quote: "compile, complain, find typo"

Yeah, I definitely do a lot of complaining. I probably spend 50% of the time I spend programming complaining about it!

Quote: "I use Notepad..."

I wouldn't expect anything less from you, CG.

Quote: "the slower you develop, but the fewer bugs you introduce"

That's true, but do you think it's worth spending the extra time to avoid bugs, or doing a lot of development and debugging at the end?

Quote: "I've been known to code the whole thing without compiling once."

Awesome, I wish I could be that confident in my code. :/

Quote: "Still find keeping a pen and paper near the computer to be one of the most value things."

I learnt that fairly quickly, I always have a notepad and a pen on my desk, it helps massively when you're trying to work something out.

Quote: "Then I saw Indicium had started it, and was like, "WTH!? Indicium!!??""

I had no idea anybody paid attention to me around here.

Quote: "Sometimes I have no option as it is impossible to execute from the development machine"

Wow, that must take quite a bit of skill!

Indi.

Daniel TGC
Retired Moderator
18
Years of Service
User Offline
Joined: 19th Feb 2007
Location: TGC
Posted: 20th Jul 2011 00:25 Edited at: 20th Jul 2011 00:27
I code like someone addicted, then the spell breaks and I wonder how the hell I wrote all this. Then I write a script and produce a three hour video tutorial about it, and pretend I know what I'm doing! When I'm into something I don't think, I do plan. I just don't think, the idea's get written down, and I just hack away at it until it resembles something useful. I've been coding for about three days now, writing a Procedurally Generated Text based RPG game. I've been blogging the code every day at http://blog.darkprinciples.co.uk/ it pretty much goes like this with everything I do. Manic, obsessive streaks followed by long periods of not doing much of anything. Why am I writing a Text based RPG game? I dunno, it's just fun.

Oh and I compile after writing every new function. Got to test that function, I'm not happy until I'm sure that it's working acceptably. I'm not worried about perfect, perfect can wait until I come back to the code next month. The goal initially is to make it work, then spend a ton of time optimising it, while shaking my head at all the wasteful logic I've written.

Oh, and I also order pizza. Pizza and icecream.
xplosys
19
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 20th Jul 2011 01:07
Sounds like Episodic Codaholism. And I see it gives you the munchies too. So after weeks of frantic coding, pizza and ice cream you become "Pizza the Hutt". That's cool.

Brian.

Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 20th Jul 2011 04:41
I think the most important thing in coding is organization. I may have only done JSP professionally for a short time, but coding with a team is quite different than doing it all yourself. You'll often be asked to implement features into code you've never seen before, and that code could be several hundred different source files.

Travis Gatlin
16
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 20th Jul 2011 05:44
I code.... unknowingly. I go in there and write in commands and then start adding in the parameters to the command that i think may do the right thing (usually they don't) i then adjust the parameters of the command until they get close to what i want, then i compile to test it... that's what i do.... if ya don't like it, well... i don't blame you for that one lol

Your signature has been erased by a mod please reduce it to no larger that 600 x 120.
crispex
17
Years of Service
User Offline
Joined: 22nd Jun 2007
Location:
Posted: 20th Jul 2011 09:19
Similar topic: Who here often gets coders hangovers? Basically it's when you stay up until 3 in the morning, then when you wake up after you go to bed, you've got the worst headache.

I just now realized I've had a typo in my signature for the past 3 years.
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 20th Jul 2011 10:48
Quote: "Wow, that must take quite a bit of skill!"
Maybe. A *lot* of practice helps.

One example is when a customer has a link to a third party tool that we don't have access to currently on our development machine (realtime flight availability is a good one where I work, and can be because we don't want to buy it or the current configuration would be a massive pain to change to use it - ie. more than the quote for the job).

But again there are always ways around things to make things easier. Working on a client's machine is one way (although a massive pain with possible code differences and speed issue over network links), another is to literally bring back what you require. So in my flight availability example I just copy all the responses to set API queries, and then produce a dummy one back here that responds with the same messages. Works pretty well.

But the biggest pain is coding a fix to someone's code. I had one the other day that had been there since almost day one. It is embedded in code from 1991 in an area of the system (6500+ programs) I know little about. Fun fun fun... Not just checking your work but finding out how the original worked. Sigh...

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Rampage
17
Years of Service
User Offline
Joined: 4th Feb 2008
Location: New Zealand
Posted: 20th Jul 2011 11:21 Edited at: 21st Jul 2011 03:36
I am quite a lot like that. I code something new, and compile to test it out.
Not every function, at least not the ones I'm sure will work.
But I feel that every compile that adds just that little bit more into the program, or even a fix that has been bugging you for a long time, is worth it all.
I feel great seeing stuff added or fixed and it really encourages me to keep at it.

Regards,

Max
Red Eye
16
Years of Service
User Offline
Joined: 15th Oct 2008
Location:
Posted: 20th Jul 2011 12:16 Edited at: 20th Jul 2011 12:34
I used to test alot of times. But now I recently implemented Lua and my console to edit values at different adresses, it made my life easier, so i can see what happens when i change a value, istead of recompiling again and again, here is a screenshot:

This is what i do when i want to test a value and work on it realtime:



And after that I get this:


Note: you can use the name of the variable also .

But i use the above, to "test". But if I add a feature, i naturally compile it loads of time to test the major things.

Quote: "Similar topic: Who here often gets coders hangovers? Basically it's when you stay up until 3 in the morning, then when you wake up after you go to bed, you've got the worst headache."


I love those moments, thats when i dont rage quit my own software.

ShaunRW
DBPro Developer
17
Years of Service
User Offline
Joined: 7th Jan 2008
Location: Brisbane, Australia
Posted: 20th Jul 2011 16:25
I compile at every small change. So in my current project, I'm making a console so I can watch and change variables. It has already made things a lot faster and easier.

Gil Galvanti
20
Years of Service
User Offline
Joined: 22nd Dec 2004
Location: Texas, United States
Posted: 21st Jul 2011 08:49 Edited at: 21st Jul 2011 08:50
It took me a while with many rewrites of projects and many years of coding experience to realize the advantage of coding projects in modules, which is what I do now. For example, I have a terrain module, a camera module, an entity module, etc. all that are able to stand alone and are actually developed individually, which I then abstract down to the point that when I decide to add them to an engine, all that is required is including the file and calling "terrain_init()" to set things up and "terrain_update()" to update everything. Makes it really easy to stop things from interfering with each other and plug modules in and out of different projects.

As far as how often I compile, it depends on what I'm doing. I compile every time I'm ready to see the results. Sometimes that means coding 5 new functions that I need to get the desired result, and sometimes that means changing the value of a variable.

I've also somewhat recently discovered the advantage of using lua for run-time scripting and ini files for variable definitions, since they both mean you don't have to recompile the code to change a variable or the behavior of a high-level function.


bergice
17
Years of Service
User Offline
Joined: 5th Jun 2007
Location: Oslo,Norway
Posted: 21st Jul 2011 15:15
OOP is the way to go, that's why I now use GDK instead. It makes it so more structurized and easier to change or add new content by having the different parts of the games in their own files and classes. But it can still be hard to find a proper way to communicate between the classes. You need to plan things out ahead so you don't get stuck at a point and realize you need to remove a ton of code.

Hi
xplosys
19
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 21st Jul 2011 16:00
Quote: "structurized"


I assume that's NOT one of their selling points.

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 21st Jul 2011 17:33
I program everything first, and when I'm finished, I compile. And it works. Flawlessly. I'm awesome.

...

Not really, I always have a base structure I program for every game (call it a template), and after that works I compile after every new feature I add. Complex features like adding an item to the game, or an effect, take a long time. Simple features like a bullet usually work without any complications.

Mega Mash Mothers just reached 7777 lines of code 3 days ago, and it takes 8 seconds to compile! (That's my super duper awesome computer setup, my old system, 1.6 GHz single core, 2 GB ram, took 45 seconds at 3000 lines of code).

My point being, compiling times increase exponentially the more complex your project becomes, and in my mind, are valuable. I should probably implement lua like someone mentioned above... Shouldn't be too hard.

TheComet

Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 21st Jul 2011 18:18
Quote: "That's my super duper awesome computer setup"
Hmm, that compile time is pleasingly better than the old one (I don't really play games on my PC anymore so haven't upgraded in a while). What specs have you got on the new one?

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 21st Jul 2011 18:50
CPU - AMD Phenom II X6 1090T overclocked @ 4.2 GHz (from 3.2 GHz)
GPU - nVidia GTX580, PCI-e
RAM - 2x 4 GB Kingston overclocked @ 1.6 GHz (from 1.2 GHz)
HDD - 1 TB Hatachi
PSU - 1000W thingy
Motherboard - ASRock 870 Extreme3
CPU cooler - Corsair h70 watercooler

Bus speed overclocked to 120 MHz (from 100 MHz).

It is considerably faster than my old computer, but 8 seconds is still too long for me

TheComet

Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 21st Jul 2011 19:24
Depends what you do with your code really. Where I work we have always had QA standards to stamp out oversized code. For example lots of IFs in a row are totally killed off if you can do it with a single command, which a lot of the time you can.

And it depends on the language. The main one I am using at the minute will only compile each modular file if it has changed. So my current project, for example, has a load of trajectory code in one file, and another load of 3D stuff in another. Neither change pretty much ever, so they are not compiled every time. Is quite nice if you follow a modular design.

Nice setup BTW. Bit overkill for me though. Mainly just compile smallish programs these days and I don't think I've anything that takes over 10 seconds at the minute, so will leave as it is for now (plus my Mac Mini works well currently for compiling iPhone stuff).

Still, totally miss VB6. Did a lot of coding back in the day on it, and was ace for testing as it is interpreted when you run. So nothing is compiled and runs instantly. All works really well, and has the advantage of being faster when you do compile fully for a release Ah, wiping away that tear now...

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Gil Galvanti
20
Years of Service
User Offline
Joined: 22nd Dec 2004
Location: Texas, United States
Posted: 22nd Jul 2011 00:55
Quote: "Mega Mash Mothers just reached 7777 lines of code 3 days ago, and it takes 8 seconds to compile!"

Only 8 seconds? I have a project that is around 8000 lines and it takes about 40 seconds to compile...and I have a really good computer. I wonder what makes such a big difference.


TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 22nd Jul 2011 10:29
@ Gil Galvanti

I comment everything I can in my code, so it's safe to say that half of those lines are just comments Maybe that makes a difference?

Only other thing I can think of is the way our CPUs process info. My CPU may only need 12 clock cycles to process a dword, where yours might need 24 clock cycles, or even 48 (just guesses based on my knowledge of micro controllers). That's where many people make mistakes, when thinking that a quad core from intel @ 3.2 GHz is just as good as a quad core from AMD @ 3.2 GHz. It's not.

TheComet

Login to post a reply

Server time is: 2025-05-21 05:21:34
Your offset time is: 2025-05-21 05:21:34