What are you doing in game development today?

Started by Dracos, January 03, 2006, 09:00:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dracos

A similar vein of topic...

Today I be merging codebases to produce the hopefully stable base for Pirates.  At this rate I will either lose my sanity or have an excellent start come the fifteenth.

Dracos
Well, Goodbye.

Dracos

Tweleve hours and a finished merging later, I think my sanity fled sometime after midnight.

Dracos
Well, Goodbye.

twentytwo

:?

Tried out the DigiPen Webcasts over at the Microsoft site. Kind of silly, but I liked a few of the questions asked after the formal presentations.

:)

Lately, I've been trying my hand at DirectX 9... Managed. It's not as fast as I'd like, but it definitely works... which is always a good thing.

:!:

Right now, I'm converting the game from the webcast (StarTrooper) into DirectDraw (don't ask me why). Along with it, I'm trying to add a few things, like an AI that runs the enemies on the screen (just for fun). It might be intesting...

This spring I'll be taking on a class on the subject, so after that, I'll start on something a bit more... original.

-22

Dracos

Digipen webcasts?


Anyhow, finally got my damn new dev machine  Thing is huge.  I could kill a man by dropping it on him.

Got the codebase for pirates pretty steady now.  Need to clean up the new machine and transfer it over, get SVN setup and also merge in the joystick code, but that's not a huge deal.  =D

Additionally been messing with Torquedev.  If you ever find yourself working with Torque, it's a pretty awesome program.  Sort of like a Visual C++, save designed to work over torque and to tie in and allow breakpoint debugging (THANK YE!)

Dracos
Well, Goodbye.

twentytwo

Dracos-
QuoteDigipen webcasts?

That would be these:
http://www.microsoft.com/events/series/msdnvideodev.mspx

Word of Warning:
Take it with a grain of salt. They're nowhere near as good as they sound... (though the new ones might not be too bad...)

Dracos

Last few days have been devoted to training the team in the various tools of trade.  Mantis, SVN, a C++ IDE, the usual.  They didn't groan too much, thankfully, even though they're taking time getting used to SVN.

I'm with the common perspective now.  It's significantly more flexible and easy to run compared to CVS.  The various crazed disasters have generally been on the order of ten-twenty minute recoveries, and I suspect they'll get much faster as I get more experienced with the admin tools and more specifically, my team stops making mistakes in that area and fully adapts to using it.

The prevention of non-atomic commits alone is a big saver with projects like this, as well as its ability to recursively catch any and all modified files and pull them up in a reasonable list.  Very keen.

Dracos
Well, Goodbye.

twentytwo

Well, after a good week of fighting the .NET WinForms, I finally managed to get a loop with a fairly good frame rate. Apparently when Flipping a backbuffer using Managed DirectX 9.0 's DirectDraw component, you can't Asyncronously flip with VSync (vertical-blank sync) turned on. If you try, it slows down the program to the VSync refresh rate (60 fps, if you're lucky; 30 fps if you're unlucky). Either way, I now have a 500 fps loop (it does nothing...). Joy.

Now to actually plug a game into it...
-22

EDIT: Ak! Found a bug in the WinForms. If you contort the border of a window during runtime (change the border style from FixedSingle to None) and then Maximize and Restore the window, it starts to give inaccurate values for window length and width...! (Ever increasing or ever decreasing, depending on Windows build...) Grr...

Dracos

In one window I'm doing UI design ("This button, no that..mmm, bigger, no smaller...two screens, no one!") which has seen about a number off designs get scrapped tonight.  In another I'm helping debug windows input handling whiich while clear enough isn't something I've had to directly touch in years.

Dracos
Well, Goodbye.

twentytwo

Well, I officially finished my first day of my first official "game programming" class. So far, I like it, though it is a bit different than I would have expected...

There are three projects: Cat and Mouse, Terrain, and Custom Game. The first involves writing AI for many cats and a single mouse that makes the cats smart enough to chase down the mouse and the mouse smart enough not to get caught. The second is to build terrain using a height/color grid and to build a viewer that lets you look around at it (of course, this will involve some Level of Detail algorithms of some kind...). The last one is the most interesting, which allows me to make a game of my own choosing, so long as it either has a definite win/lose situation (Street Fighter) or a tallied score (Pacman) (I'll probubly go with some kind of space shooter, as that's my favorite type of game...).

Anyway, it sounds like fun.

More as they develop...
-22

Dracos

Well, aside from a hard drive blowing up(fixed now), I've been working on interface and sound stuff, but not as much as I'd like.

It's pretty clear that managing a ten person squad eats a lot more time.  Looking on, I could easily see doing almost no development work when managing a 40-50 person squad, which itself would be something odd.  It's really hitting me about the whole lead coder spiel I read before, giving said individual almost no important tasks so they can, at any time, drop it to cover any of the other tasks (which they should be able to do and help the lower coders with).  I'm still doing that a ton since I'm technically at the top of the coding heirarchy, but lucky I've got good folks.

Dracos
Well, Goodbye.

twentytwo

Well, it turns out my little analysis of DirectX was wrong. The problem wasn't VSync, but rather the default settings for the DirectDraw Device. Apparently, when creating the Device, you have to set it to either HardwareOnly or EmulationOnly. There is a default that the system chooses, which is usually Hardware (which makes sense for Direct3D, but not DirectDraw). Apparently Emulation is ALOT faster... (the empty loop is now 960 FPS, not 450...). Of course, this assumes I won't be doing anything more complex than simple surface blitting and backbuffer flips...

Now that that's done with, it's time to go back to C++ and OpenGL (glut32.dll)... (at least for the duration of this class -> up until this coming summer...)

-22

Dracos

Man, it's been a long couple of weeks.  Quickly (though not as quickly as I like) approaching alpha level on the single player.  We've got pretty much every basic mechanic represented in its untweaked gory fashion.  Just adding in player selection today and keybindings.  My level dev teams got the phases speech...  I need a rocket so I can actually do the whole "I'm going to be coming through your ceiling the second you're 'done' with it" bit.

Ah, the dangers of promises :D

Dracos
Well, Goodbye.

Dracos

Quote from: "twentytwo"Well, it turns out my little analysis of DirectX was wrong. The problem wasn't VSync, but rather the default settings for the DirectDraw Device. Apparently, when creating the Device, you have to set it to either HardwareOnly or EmulationOnly. There is a default that the system chooses, which is usually Hardware (which makes sense for Direct3D, but not DirectDraw). Apparently Emulation is ALOT faster... (the empty loop is now 960 FPS, not 450...). Of course, this assumes I won't be doing anything more complex than simple surface blitting and backbuffer flips...

Now that that's done with, it's time to go back to C++ and OpenGL (glut32.dll)... (at least for the duration of this class -> up until this coming summer...)

-22

That sounds wrong.  Like a card issue.  Emulation or not, it does have to go through the video card to write to the screen, which itself maintains (obviously) only hardware buffers.  Blitting, if done with zero per pixel stuff, should be faster by a fair margin in hardware as it just stores the whole thing there.  Software/Emulation is better when doing lots of fine processing work that the card isn't optimized to do and just sending the final buffer to the card.  it should, on simple blits, be slower since after all, it has to do a send to card each frame.

Dracos
Well, Goodbye.

Dracos

Presented yesterday before the media.  I must've been on drugs or something when I used Ruiz as one of the graders, because the woman is crazy to work with.  Simply no direction whatsoever. "Yeah, just go out and speak...knock on the door when it comes close to time".

And it interrupted a neat discussion on the proper usage of odds in video games.

Dracos
Well, Goodbye.

twentytwo

Quote from: "Dracos"
Quote from: "twentytwo"Apparently Emulation is ALOT faster...

That sounds wrong. ...Blitting, if done with zero per pixel stuff, should be faster by a fair margin in hardware as it just stores the whole thing there. Software/Emulation is better when doing lots of fine processing work that the card isn't optimized to do and just sending the final buffer to the card. it should, on simple blits, be slower since after all, it has to do a send to card each frame.

Yeah, I know it sounds wrong (hardware acceleration should ALWAYS be faster than software emulation - almost by definition). Just remember, this is Managed DirectX, so there's a good chance that there's something else going on I don't know about; my guess can only be made based on the results it gives me. Also, keep in mind that I don't have a complete game yet, so all I'm writing to the screen is the FPS and a whole lot of black. Since I'm not doing anything too taxing, the results I'll get will be inaccurate [at best]. Once I have a working demo that actually does something, I'll update my guess...

Work in progress...
-22