| Author |
Message |
Tsophika
Gamorrean
Joined: 14 Jan 2008
|
 Posted: May 02, 2008 00:35 Post subject: |
   |
|
I'm of the opinion that it would be best to stick with the first level for now. No doubt Talay would introduce a series of new issues. Maybe get the engine functioning very well, tweak the speed and AI issues, and implement some extra features such as the PDA now so that everyone has a simple point of reference.
By the way lucius - what's your experience in programming? Have you created realtime engines before? You seem to have quite a handle on problems and are quick to implement adjustments.
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 01:04 Post subject: |
 |
|
Tsophika wrote:
By the way lucius - what's your experience in programming? Have you created realtime engines before? You seem to have quite a handle on problems and are quick to implement adjustments.
Yes I'm experienced... I started coding on the Commodore 64, making 2D strategy/RPG style games for fun. My first "real" 3D engine was a software rasterizer before the Voodoo cards came out - which was a full 6 DOF renderer with software zbuffer, colored lighting, perspective correct texturemapping and so on. Even then I wrote the full model editor and level editor, well essentially a full game engine including AI, controls, collisions, and more. And I've been writing code since, and working with GPUs since the Voodoo1... I've coded in everything from Commodore 64 Basic, to Pascal, C, C++, x86 ASM, microcode for various devices, PowerPC ASM, and so on.
Does that answer your question?
Thanks for giving your opinion on the new features/level question. That's the kind of response I was looking for, as I said before I can see the benefits of going either way.
_________________
DarkXL....http://darkxl.wordpress.com |
|
Darth Oosha
Trandoshan
Joined: 24 Sep 2003
|
| Posted: May 02, 2008 02:55 Post subject: |
|
|
DF4GL4ever wrote:
Quick question: when we set the DFolder path, do we direct that straight to Dark Forces Data? I only have the Mac DF Dark Forces Data folder and DarkXL crashes when I load with the path to Dark Forces Data. I'm running Win XP Pro on an iMac, OpenAL is installed.
Suggestion: Try renaming "Cutscenes" to "LFD", and moving all the files from Weapons.gob into one of the other four gobs.
sheepandshepherd wrote:
And about that explosion sprite - I think what sweatervest means is that the sprite should always face the player, not just stay vertical like the stormtrooper sprites. When you shoot at the ground, you should see exactly the same view of the sprite as if you shot at a wall.
FWIW, System Shock got away with doing that with all sprites - when you stand on a biped and look down at it, it looks like it's lying sideways on the floor instead of standing. But I still think the best solution is to just block the player from looking straight up and down, like the original game did; otherwise you also mess up things like the drop into the reactor core in Robotics.
Marathon: Durandal faced a similar problem (sprites in a full-3D engine), but I'm not sure what approach it takes.
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 03:14 Post subject: |
|
|
Darth Oosha, have you played the demo? Does it work on your system? Do you get sound? And the other questions...
Thanks.
_________________
DarkXL....http://darkxl.wordpress.com |
|
Darth Oosha
Trandoshan
Joined: 24 Sep 2003
|
| Posted: May 02, 2008 03:17 Post subject: |
|
|
No to the first; I'll report in as soon as I get around to trying it.
|
|
Fenwar
Admiral Ackbar
Joined: 15 Sep 2003
|
| Posted: May 02, 2008 03:22 Post subject: |
|
|
Finally had a chance to check this out... already we're up to build 4.
One small hiccup in getting it running - my DF folder is c:\Program Files\games\DARK - the game crashed initially but when I replaced this in the config with the MS-DOS pathname (c:\progra~1\games\dark) it worked straight away.
A) I made it through the mission right to the end and received the completion message.
B) Performance-wise I had no problems; however with the sprite rendering I have the same issue as BlazingPhoenix. Tried tweaking the screen res, hardware acceleration slider and so forth without any joy.
System specs as follows:
Athlon XP 3800+ (2.4 GHz), 1GB RAM
Radeon X1900 GT (drivers at version 6.14.10.x)
1024x768,75Hz
Windows XP SP2
Are we the only people using ATI cards, then?
C) The movement is obviously not yet quite right and to me the game world felt "larger" - perhaps this is just to do with the transition from DF's low resolution to 1024x768 - but for me, this game feels like Dark Forces. The sounds and textures being the same is the key to this, I think. (Perhaps this coincidentally explains why I was so disappointed with Jedi Knight...)
D) Only other thing was finding it a tiny bit disorientating when I died to simply be warped back to the start. At first I thought it was caused by a bug but I guess its simply that Kyle's death sequence is missing.
All in all though, this is great! 
|
|
DF4GL4ever
Gamorrean
Joined: 15 Apr 2004
|
| Posted: May 02, 2008 05:51 Post subject: |
|
|
Hah the 8 character pathnames are the issue, along with the LFD and the no weapons.gob in the DOS game. It's working now so thanks for the suggestions  So yeah on the iMac with Radeon X1600 graphics the sprites are pretty scrambled and the HUD indicators aren't working right either. I have a screenshot here: http://x-plane.org/home/xpglegg/darkxl.jpg I see that the other ATI users are having these issues so I look forward to the next builds!
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 06:14 Post subject: Mac Data |
|
|
Can you write up a clear set of steps to get the Mac data working for me? I'll put up the information on the website so anyone with the Mac data can play the demo.
Thanks for working that out guys 
_________________
DarkXL....http://darkxl.wordpress.com |
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 09:02 Post subject: Alpha Demo Build 5 |
|
|
There is a new build, the original link has been updated. Make sure you're downloading Build 5
This build should fix the graphics problems on GeForce FX and ATI cards. Anyone that had graphics problems, such as corrupted sprites and incorrectly rendered HUD please try this out and let me know.
Collision fixes were taking more time than anticipated so they will be in the next build.
Now for the list of bug fixes/new features in no particular order:
*Added Optional "MouseInvert" (in DXL_Settings.txt)
*Added "MouseSensitivity" (in DXL_Settings), where 50 = default, higher is more sensitive, lower is less sensitive.
*A screenshot key has been added ( F8 ).
*ATI/GeForceFX rendering errors fixed.
*Enemy LOS should be fixed.
*Stormtroopers play the correct melee death animation.
*Strafing and moving forward no longer causes the player to move faster.
_________________
DarkXL....http://darkxl.wordpress.com |
|
dinohog
Dianoga
Joined: 02 Dec 2005
|
| Posted: May 02, 2008 09:57 Post subject: Alpha Demo Build 5 |
|
|
Performance on Athlon XP 1600+ (1.4Ghz), 512 Meg Ram, NVidia FX5200, Creative SB live sound, report.
On build 5 the graphics seem to render fine. The sound was okay too. Unfortunately the sprite animations and general running of the game was far too slow. Even set at 800x600 fullscreen and texfilter: 1, the game played too slowly to be really enjoyable. It seemed I could move around almost smoothly but click the mouse and wait for fire, wait for hit, wait for animation on the sprite to react was not good. It was too slow for me to explore the entire level and all secret areas but I could play to the end and see the mission complete text.
My big question is will optimising the game engine produce reasonable performance or will minimum specs be set much higher?
I will acknowledge that I am potentially expecting too much at this early stage. I will say that it is very enjoyable to get back to DF and I look forward to further updates. This is a great start.
Dino.
|
|
BlazingPhoenix
Ree-Yees
Joined: 22 Mar 2008
|
| Posted: May 02, 2008 10:31 Post subject: |
|
|
Rendering looks fixed, but now it crashes every time I start DarkXL. x_x
|
|
bak1977
Dianoga
Joined: 28 Apr 2008
|
| Posted: May 02, 2008 11:26 Post subject: |
|
|
build5 is running fine so far, but:
- in the secret area you find the ir-googles i couldnt pick up some med kits even i wasnt at full health
- the ai seems to stutter fast from left to right standing in place sometimes (hadnt this in other builds)
|
|
Fenwar
Admiral Ackbar
Joined: 15 Sep 2003
|
| Posted: May 02, 2008 17:18 Post subject: |
|
|
That's fixed the sprites for me too.
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 17:57 Post subject: Re: Alpha Demo Build 5 |
|
|
dinohog wrote:
Performance on Athlon XP 1600+ (1.4Ghz), 512 Meg Ram, NVidia FX5200, Creative SB live sound, report.
On build 5 the graphics seem to render fine. The sound was okay too. Unfortunately the sprite animations and general running of the game was far too slow. Even set at 800x600 fullscreen and texfilter: 1, the game played too slowly to be really enjoyable. It seemed I could move around almost smoothly but click the mouse and wait for fire, wait for hit, wait for animation on the sprite to react was not good. It was too slow for me to explore the entire level and all secret areas but I could play to the end and see the mission complete text.
My big question is will optimising the game engine produce reasonable performance or will minimum specs be set much higher?
I will acknowledge that I am potentially expecting too much at this early stage. I will say that it is very enjoyable to get back to DF and I look forward to further updates. This is a great start.
Dino.
The problem might be that it is going through the pixel shader 2.0 path on your GPU, but those cards were notoriously bad at shader2 support. I'll put in an option to use a lower shader model - though you'll sacrifice some features (the light falloff wouldn't be as smooth for shooting or headlamp right now, some extended features later). I already support shader 1.1, it's just that your FX card reports 2.0+ even though it is very slow in that mode.
In addition the way geometry is submitted and rendered could be more efficient - I just wanted to ensure functional correctness over different hardware before spending too much time optimizing.
_________________
DarkXL....http://darkxl.wordpress.com |
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
|
BlazingPhoenix
Ree-Yees
Joined: 22 Mar 2008
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
|
BlazingPhoenix
Ree-Yees
Joined: 22 Mar 2008
|
| Posted: May 02, 2008 18:43 Post subject: |
|
|
X1300. Not sure about the memory, I'll look when I get home
(at school)
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
| Posted: May 02, 2008 19:47 Post subject: |
|
|
lucius wrote:
And upon request, I will not include the D3DX dll
I am running Vista 64 and I needed to put your bundled dll in my system folder (without it the program crashed, saying it couldn't find the D3D dll), so just to let you know I think 64-bit users might still need the dll. Perhaps it can be given its own download link on the DarkXL page.
I just tested the fifth build. I know you fixed the LOS for the enemies, but whatever else you did to the AI has for some reason made it alot more fun (or maybe I'm just in the DF mood right now... either way I was much more absorbed in the action this time).
I was going to say that for the fourth build (and all the previous) there was a small sound bug where your gun shots would move around based on how you were moving (for example, strafing left made the gun noise come out of the right speaker) but that seems to have been fixed. Everything else seems fine, and is running quite fast... I had to push my full-screen anti-aliasing all the way up to 16xQ before it started slowing down (running at 1680x1050).
About the explosion sprites, I think all old games that first introduced looking did the same thing System Shock did, like in DF if you looked 45 degrees down or however far it lets you, a stormtrooper would look like he is leaned back looking up straight at you. I don't think a hard limit should be placed on the vertical look though, because even at less than straight up/down those sprites still look skewed, and honestly I would rather have the gameplay element of complete looking ability and skewed sprites than better looking sprites and less looking. In fact, I think it should just be an option, like "Restrict Viewing Angle" or something, for those who want the true DF experience. Lucius please correct me if I am wrong about this but sprites by default always render as if they are facing you, like in DF, so in order to prevent the problem of, say, stormtroopers lying down on the ground below you, lucius implemented a rendering feature that adjusted the sprites to render vertically, so really fixing this would involve just flagging certain sprites, specifically the more spherical and symmetrically shaped ones like explosions and projectiles from the repeater rifle and fusion cutter, to ignore or skip this rendering correction. So the problem is that too much image processing is going on, instead of not enough.
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 20:06 Post subject: |
|
|
sweatervest wrote:
lucius wrote:
And upon request, I will not include the D3DX dll
I am running Vista 64 and I needed to put your bundled dll in my system folder (without it the program crashed, saying it couldn't find the D3D dll), so just to let you know I think 64-bit users might still need the dll. Perhaps it can be given its own download link on the DarkXL page.
Microsoft seperated the D3DX.dll updates from the main DirectX runtimes, thus you could have the latest drivers/runtime but not the latest D3DX.dll.
In addition, since the program relies on the dll it was compiled to use, it may not need the latest dll but a previous one. The proper solution would be to setup a link to microsoft's download page where you can get the installer specifically made to handle this problem. I wanted getting the demo up and running as easy as possible, but now that it works for most people I think I'll take the "proper" approach now.
sweatervest wrote:
I just tested the fifth build. I know you fixed the LOS for the enemies, but whatever else you did to the AI has for some reason made it alot more fun (or maybe I'm just in the DF mood right now... either way I was much more absorbed in the action this time).
I was going to say that for the fourth build (and all the previous) there was a small sound bug where your gun shots would move around based on how you were moving (for example, strafing left made the gun noise come out of the right speaker) but that seems to have been fixed. Everything else seems fine, and is running quite fast... I had to push my full-screen anti-aliasing all the way up to 16xQ before it started slowing down (running at 1680x1050).
Thanks, I'm glad the experience is getting better for you The AI isn't finished yet, though.
sweatervest wrote:
About the explosion sprites, I think all old games that first introduced looking did the same thing System Shock did, like in DF if you looked 45 degrees down or however far it lets you, a stormtrooper would look like he is leaned back looking up straight at you. I don't think a hard limit should be placed on the vertical look though, because even at less than straight up/down those sprites still look skewed, and honestly I would rather have the gameplay element of complete looking ability and skewed sprites than better looking sprites and less looking. In fact, I think it should just be an option, like "Restrict Viewing Angle" or something, for those who want the true DF experience. Lucius please correct me if I am wrong about this but sprites by default always render as if they are facing you, like in DF, so in order to prevent the problem of, say, stormtroopers lying down on the ground below you, lucius implemented a rendering feature that adjusted the sprites to render vertically, so really fixing this would involve just flagging certain sprites, specifically the more spherical and symmetrically shaped ones like explosions and projectiles from the repeater rifle and fusion cutter, to ignore or skip this rendering correction. So the problem is that too much image processing is going on, instead of not enough.
Actually DF had the "vertical" sprites for enemies too, it would look really weird when looking up and down if it did not since the game relied on this so much in areas. They did not have quite the same look as DarkXL, however, because of the way looking up and down skewed the view rather then properly rotating it (which wouldn't have been possible with DF's engine anyway - atleast not without impractical cost) which caused all the vertical lines to remain vertical and parallel to each other. However some other sprites should always face the camera, such as the explosion sprites (like you mentioned). Also I will make limiting the up/down view, like DF, an option for those who want it, and for everyone else I'll interpolate between the "vertical" sprite orientation and the pure camera facing orientation as the view angle becomes extreme to avoid seeing sprites edge on. This should make it look better without losing the ability to have enemies that appear to stand straight up.
As for making sprites always face the camera, that actually would be slightly cheaper. Putting in code for that is easier, actually, then just setting up the flag and allowing it to be set in the scripting system - although that won't be hard either. I just have to do it, and it hasn't been high priority yet. I'll see about fixing the explosion sprites for the next build.
_________________
DarkXL....http://darkxl.wordpress.com |
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
| Posted: May 02, 2008 21:02 Post subject: |
|
|
lucius wrote:
As for making sprites always face the camera, that actually would be slightly cheaper. Putting in code for that is easier, actually, then just setting up the flag and allowing it to be set in the scripting system - although that won't be hard either. I just have to do it, and it hasn't been high priority yet. I'll see about fixing the explosion sprites for the next build.
Yeah that doesn't seem very pertinent right now. I imagine once you've implemented the weapons that use sprite projectiles (I was actually wondering how DF does laser blasts... are they really simple models or something else?) the skewing problem will become much more noticable and important.
So I was playing around between DF and DarkXL (I was actually wondering if the laser blasts in DarkXL were too small, and I concluded that they are not) and realized that when I was talking about the delay with the pistol I was wrong. It actually still waits until the end of the animation to fire (I was watching very closely, I hit the button, the gun almost immediately rises up into its "firing" animation frame, then as soon as it sets back down into its ready position frame the laser blast and sound are spawned. I examined the animation sequence for the pistol very closely in both programs, and I am almost positive that in DarkXL the pistol is missing an animation frame between the "firing" frame and the "ready" frame (the pistol no longer glows in this frame but it is still aimed slightly higher than normal. This frame is displayed after the shot but not right before it in DF, so the animation goes "ready", "firing", "in-between", "ready"). Also, there is still a very small delay between when the fire button is pushed in DarkXL and when the animation sequence starts (as in a slightly larger delay than DF). I tried testing it with the blaster rifle but since its animation sequence is so quick it's pretty hard, but I think I am noticing that the rifle also spawns its blast at the end of the animation (along with the sound). Is anyone else noticing this because it may be a problem with my setup (for example I have some programs running in the background all the time, I might try a "bare" test right after I do some cleaning up in the task manager).
Also, in build 5 I think I tend to get hung up on geometry a little more than I used to. I always got hung up a little on the spiral stairs but that is where I noticed an increase this time. I could also consistently recreate some instances of getting blocked by an invisible wall between sectors (specifically in between the room with the switch that opens the room with the plans, and the room with the plans).
Finally, I had two ideas for important yet simple (maybe) additions to one of the next builds: a crosshair, and keymaps for next and previous weapons.
|
|
The MAZZTer
Death Star
Joined: 25 Sep 2003
|
| Posted: May 02, 2008 21:14 Post subject: |
|
|
sweatervest wrote:
I am running Vista 64 and I needed to put your bundled dll in my system folder (without it the program crashed, saying it couldn't find the D3D dll), so just to let you know I think 64-bit users might still need the dll. Perhaps it can be given its own download link on the DarkXL page.
There are two possibilities here:
1) You don't have the latest version of DirectX 9 installed, thus you should install it. Vista shipped with DirectX 10 and DirectX 9.0c (which is completely separate now, like how the different .NET versions are separate) but there have been incremental updates to DirectX 9 since Vista shipped that have not increased the version number. Downloading the DirectX Web Installer should update your DirectX installation properly.
2) The DLL required is a debug version of DirectX only installed with the DirectX SDK which is slower than the release version of DirectX. Public releases shouldn't be compiled for the debug version.
lucius wrote:
Microsoft seperated the D3DX.dll updates from the main DirectX runtimes, thus you could have the latest drivers/runtime but not the latest D3DX.dll.
Sounds like you possibly compiled against the debug version. D3DX9_*.dll are the release versions of DirectX 9, D3DX9D_*.dll are the debug versions. The debug versions are only installed on a user's system if they install the DirectX SDK.
Since the debug versions are slower than the release versions, you really should make sure you're compiling for the release version of DirectX whenever you build a public release. The debug DirectX is only useful if you have access to the source code anyway and intend to debug a game.
If you didn't compile against the debug release, the only other possibility is that you haven't realized MS has released updates to DX9.0c which didn't update the version number. This is probably where all the different numbered DLLs came from, and if you haven't updated in a while you might be missing a few recent ones you assumed were separate since you didn't see any version number increases anywhere on the Internet.
Here's another DarkXL bug... if DarkXL can't find the Dark Forces files it crashes... it should handle it more gracefully.
It sounds like it not being able to handle long filenames is probably just a result of it not being able to handle spaces in paths.
[Edit: I checked the process' loaded DLLs and it seems to be loading the release version... am I imagining things or did you ship a debug DLL with it before? I'm not sure since I didn't remember about the D suffix meaning debug until I checked on my own collection of DX DLLs.]
_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig. |
|
BlazingPhoenix
Ree-Yees
Joined: 22 Mar 2008
|
| Posted: May 02, 2008 21:47 Post subject: |
|
|
Okay, I think it's 256 MB of memory(or above, I'm still not quite sure, but I know it's around 256)
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 22:26 Post subject: |
|
|
The_Mega_ZZTer wrote:
Since the debug versions are slower than the release versions, you really should make sure you're compiling for the release version of DirectX whenever you build a public release. The debug DirectX is only useful if you have access to the source code anyway and intend to debug a game.
If you didn't compile against the debug release, the only other possibility is that you haven't realized MS has released updates to DX9.0c which didn't update the version number. This is probably where all the different numbered DLLs came from, and if you haven't updated in a while you might be missing a few recent ones you assumed were separate since you didn't see any version number increases anywhere on the Internet.
...
[Edit: I checked the process' loaded DLLs and it seems to be loading the release version... am I imagining things or did you ship a debug DLL with it before? I'm not sure since I didn't remember about the D suffix meaning debug until I checked on my own collection of DX DLLs.]
Sorry but I've always compiled against the release versions for all the public builds, I do know that the debug version is slower and intended for debugging only
And I know that Microsoft has released DirectX updates independent of the version number, however most updates are just the tools and D3DX dlls and not the runtimes. The HLSL compilers are in the D3DX dll for example (also available as seperate tools for offline compiling) in DX9 (they are part of the core runtime in DX10) as well as other functionality that is not part of the core runtimes.
In fact some games, to make downloads smaller, can just package a version of DXSetup that only includes D3DX dll needed for that game.
Or to quote an online source "The 9.0c relates to the core runtime which has remained the same for some time. The updates to the runtime download include D3DX and managed DirectX which are updated bi-monthly along with the DirectX SDK. These components have their own version number." Of course on Vista the core is now 9.0L, which had to be modified to use the new driver model - and has a few minor new features.
Sorry if I sound stubborn but I just wanted you to know that I have some idea how it works 
At any rate, the web installer will work fine and I should provide a link to that. Another alternative is to setup a custom DXSetup, as per the SDK docs, with just the required files and put a link for that. But I'll stick with the web installer in case someone isn't up to date with some other component or doesn't have DX9c or DX9L.
The_Mega_ZZTer wrote:
Here's another DarkXL bug... if DarkXL can't find the Dark Forces files it crashes... it should handle it more gracefully.
You are correct, it should pop up a message box or something telling the user what is wrong, an oversight on my part.
_________________
DarkXL....http://darkxl.wordpress.com |
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 02, 2008 23:40 Post subject: |
|
|
sweatervest wrote:
So I was playing around between DF and DarkXL (I was actually wondering if the laser blasts in DarkXL were too small, and I concluded that they are not) and realized that when I was talking about the delay with the pistol I was wrong. It actually still waits until the end of the animation to fire (I was watching very closely, I hit the button, the gun almost immediately rises up into its "firing" animation frame, then as soon as it sets back down into its ready position frame the laser blast and sound are spawned. I examined the animation sequence for the pistol very closely in both programs, and I am almost positive that in DarkXL the pistol is missing an animation frame between the "firing" frame and the "ready" frame (the pistol no longer glows in this frame but it is still aimed slightly higher than normal. This frame is displayed after the shot but not right before it in DF, so the animation goes "ready", "firing", "in-between", "ready"). Also, there is still a very small delay between when the fire button is pushed in DarkXL and when the animation sequence starts (as in a slightly larger delay than DF). I tried testing it with the blaster rifle but since its animation sequence is so quick it's pretty hard, but I think I am noticing that the rifle also spawns its blast at the end of the animation (along with the sound). Is anyone else noticing this because it may be a problem with my setup (for example I have some programs running in the background all the time, I might try a "bare" test right after I do some cleaning up in the task manager).
No need, it is firing at the end of the animations. I am aware of the bug and will fix it in a future build. Thanks for testing it and letting me know though
sweatervest wrote:
Also, in build 5 I think I tend to get hung up on geometry a little more than I used to. I always got hung up a little on the spiral stairs but that is where I noticed an increase this time. I could also consistently recreate some instances of getting blocked by an invisible wall between sectors (specifically in between the room with the switch that opens the room with the plans, and the room with the plans).
I was working on the collision but decided to release early to test and see if my fix for the graphics problems on some systems worked. The collision should be much better next build. This is also why some Stormtroopers appear to flicker or rapidly turn in place (they're stuck).
sweatervest wrote:
Finally, I had two ideas for important yet simple (maybe) additions to one of the next builds: a crosshair, and keymaps for next and previous weapons.
No problem with the next/previous weapon switch, we need that (since its in DF).
As for the crosshairs, I'm a little concerned that adding crosshairs won't look right for DF. I was thinking of maybe doing a laser sight, essentially it would show up as a red dot that changes size, projected onto the geometry. But I'll wait and get people's opinions first. Of course if you're using an inaccurate weapon, like the Stormtrooper Rifle, you won't hit exactly where the dot/crosshair is.
_________________
DarkXL....http://darkxl.wordpress.com |
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: May 03, 2008 02:01 Post subject: |
|
|
lucius wrote:
As for the crosshairs, I'm a little concerned that adding crosshairs won't look right for DF. I was thinking of maybe doing a laser sight, essentially it would show up as a red dot that changes size, projected onto the geometry. But I'll wait and get people's opinions first. Of course if you're using an inaccurate weapon, like the Stormtrooper Rifle, you won't hit exactly where the dot/crosshair is.
I use a very high resolution (1920x1200), and that makes it hard to aim. I think adding an optional crosshair that can be disabled in the settings would be the best approach . . . or maybe in the future, when you have time, you could have multiple options for crosshairs, such as the laser sight. But for now, if it's not a problem with anyone, I think a simple + shaped crosshair would be best . . .
And as for the sprites always facing the camera, you meant only the explosion sprites, right?
|
|
veaudaux
Dianoga
Joined: 30 Apr 2008
|
| Posted: May 03, 2008 02:22 Post subject: |
|
|
Hey - this is my first post - I signed up just to get involved with this project
Below are some pertinent bits of my DxDiag.txt:
Quote:
------------------
System Information
------------------
Time of this report: 5/2/2008, 21:15:28
Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.070227-2254)
Language: English (Regional Setting: English)
Processor: Intel(R) Celeron(R) CPU 3.06GHz
Memory: 1022MB RAM
Page File: 460MB used, 1999MB available
DirectX Version: DirectX 9.0c (4.09.0000.0904)
---------------
Display Devices
---------------
Card name: NVIDIA GeForce 8400 GS
Manufacturer: NVIDIA
Chip type: GeForce 8400 GS
DAC type: Integrated RAMDAC
Display Memory: 512.0 MB
Current Mode: 1280 x 1024 (32 bit) (75Hz)
Monitor: Plug and Play Monitor
Monitor Max Res: 1600,1200
Driver Name: nv4_disp.dll
Driver Version: 6.14.0011.6921 (English)
DDI Version: 9 (or higher)
Driver Date/Size: 12/5/2007 01:41:00, 5773568 bytes
-------------
Sound Devices
-------------
Description: SB Live! 24-bit
Default Sound Playback: Yes
Default Voice Playback: Yes
Type: WDM
Driver Name: P17.sys
Driver Version: 5.12.0001.0514 (English)
Driver Attributes: Final Retail
Date and Size: 6/15/2007 10:47:26, 1127936 bytes
Driver Provider: CREATIVE
HW Accel Level: Full
Min/Max Sample Rate: 4000, 96000
Just wanted to be encouraging and report that I've had zero issues on this rig that haven't already been reported. Game plays great (Kyle's walk speed seems faster than I remember, but it's been a while since I've played DF), I can complete the level and access the secret areas, and I've got sound!
Keep it up - I used to sling a mean WDFUSE back in the day, and if there's anything I can to do help, consider me volunteered.
There's 7.6 billion ports of Doom. Dark Forces deserves this.
|
|
The MAZZTer
Death Star
Joined: 25 Sep 2003
|
| Posted: May 03, 2008 04:37 Post subject: |
|
|
There are lots of Doom ports because doom was open sourced, making it easy to rewrite the code to be portable to more platforms or to add in features.
Dark Forces hasn't had that advantage.
_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig. |
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 03, 2008 05:26 Post subject: |
|
|
veaudaux, thanks for the encouragement and information.
The_Mega_ZZTer is right, there is no source - I've been doing everything from scratch Fortunately there are people here to test who very much know how Dark Forces is supposed to act.
Thanks for signing up and offering your assistance.
_________________
DarkXL....http://darkxl.wordpress.com |
|
|
