Some 1.8.3 bugs have come through, so I've released a 1.8.3b to address them and also to fast-forward some of the more important 1.8.4 changes.
The first bug is in relation to player skins, and the screenshot tells it all:
While it might be a quite effective Gimp Suit, it's not the way Quake should be.
Secondly, if you use chase_active 1 and the camera goes outside a wall the game would crash hard.
Other changes are the removal of beams and temp entities limits, the removal of alias model triangles and vertexes limits, and some more minor fixes. It really should be 1.8.4 on account of these alone, but calling it that would only confuse the version numbering I've already announced, so 1.8.3b it is.
I've also included a Windows 98 build with this. This build is VERY EXPERIMENTAL. It might work, it might not, strange things might happen with it, you might need to install prerequisites, and so on. I really don't know as I don't have a Windows 98 machine to test it on.
If you're running Windows 2000, XP, Vista or 7 you most definitely should NOT use it, and I won't be entertaining ANY bug reports from people who do. This build is for anyone who has Windows 98 and is willing to try an experimental build out, and maybe do some legwork themselves with respect to getting it running.
Get it here: http://directq.codeplex.com/releases/view/44083.
Wednesday, April 21, 2010
1.8.3b Release
Posted by
mhquake
at
6:12 PM
Subscribe to:
Post Comments (Atom)
23 comments:
i tell you one bug i keep getting is when i shoot and release the trigger button it keeps shooting :S
Hmmm. Sounds like you may have DirectInput disabled or else it failed to start up. The non-DI input code is quite flaky at the moment, and has never really been tested too good. I've seen it completely blow it's top running on VMWare.
Hi MH,
Loving the engine so far. Glad to see someone working on it so actively!
recently I've noticed a bug with alt-tabbing. Whenever I tab-out and type into another window, the typing is really slow and lagged. I always am tabbing out alot in games, so I can respond to people's IMs, messages, irc, etc.
Hmmmm - I rarely test fullscreen as it's quite impossible to debug in fullscreen modes. I have just been able to reproduce this problem but I'm not certain what's causing it. Are you on Vista or 7? It might be a case that I need to hand some control of the 3D hardware back to the OS when DirectQ isn't the active app.
Yup, that was it. :) Just skip screen updates when we're not the active app.
:))
I was on Windows XP Home Edition SP3
... i know what directinput is but i don't know where it is/how to turn it on :S :S
It should start up automatically and tell you in the console that it either started or didn't.
it says it initialized at quake startup, its not the mouse im using as i tried with just the touchpad and got the same results.
i am using a separate screen plugged into the back of my laptop but i'm not using the screen attached too the lap top, could that still be a problem?
jup,having the same problem here as mentioned by meTch.Plus behavior in menues is quite jerky.Looks exactly like low performance but fps are quite high.
Running on XP SP2 with Radeon X1950XT.
OK, try switching directinput off (m_directinput 0, you can do it while a map is running and it will be saved to your config) and see what happens.
Jerky behaviour in menus - I don't quite understand. What's jerky? The mouse? The rendering? Something else?
Sorry for my english.
Moving from one menue entry to another it looks like the engine stops for half a second before the next entry is highlightet.Then hitting "Enter",again the engine will hold for a moment before it continues.
I have already tried m_directinput 1/0 wich results only in a slightly different,but in no way better,behaviour.
Ok,i think the the problem is somehow related to the "textures.pk3" i have been using.
After a clean install,with no textures,DirectQuake acts really smooth,including Mouseview and Mousebuttons.
Texture.paks with TGAs only work nice too.
The old texture.pak i was using before has TGAs and PNGs mixed together.Maybe DirectQuake doesn´t like that?
Ah, I see. Menu textures get loaded from disk the first time they're seen, so that's what's happening there. Huge textures being extracted from a PK3 won't help either, especially PNGs as they'll need to be decompressed twice - once for the PK3 and once for the PNG compression.
It's possible to move some of this to startup time which would resolve it, but make startup a little slower.
Your English is fine, by the way. I was just confused about what was jerky.
One more thing:
Are there any changes in the sound handling,by any chance?
My ripped Quake-CDTracks don´t play to well in this version.They seem to start playing and stop after aproximately one second,then start over again and so on and so on.
I tried .ogg and .mp3 format but both formats show the same behaviour.
Those Tracks play flawlessly in Darkplaces and outside DirectQuake so i´m pretty sure codecs and stuff should be okay on my PC.
Any Ideas?
Oh,by the way:
Sensationally insane performance on this new version.I get absolutely no noticable fps-drops in "Masque of the Red Death",just smooth sailing no matter how much action is going on.No other engine i tested handled this map so well,or even close.
Seems like i found my new engine of choice.
The only change there was that I compiled with a newer version of the DirectX SDK, and I use DirectX for playing them. I test all the time with a ripped CD and haven't noticed any problems, so maybe you just need a DirectX update, or maybe you could try the Win98 build (which used an older version) and see if the same happens there.
I'd be interested in finding out.
Ok,here´s what i´ve tried:
-updated directx and visual c++
-updated to SP3 for XP
-uninstalled K-Lite Codec Pack and installed an older version.
-switched between several Versions of my Sound Card Driver.
-got rid of any piece of Software that i don´t need to have.
No success!Buähuähuäh...!
I´m afraid that only leaves my beloved but stone old "SoundBlaster PCI 128" Card as the root of the problem.Although it gives me no trouble in other Games.
Funny thing is:During the "Confirm Exit" Dialog in DirectQuake ("Are you sure you want to exit Quake Yes/No")the music is playing fine.When i answer "No" and continue playing the problem reappears.
The plot thickens! I'll bet it also plays fine during the "Are you sure you want to start a new game?" dialog.
The reason why is because all the soundbuffers are emptied before showing those dialogs, which means that something in the regular sound code is not playing nice with the music code.
Now, DirectQ is the only Quake engine that uses both DirectSound 8 (for regular sounds) and DirectShow (for music) so you won't get this on other engines. DirectQ is actually quite conservative with it's regular sound code, it doesn't set an exclusive co-operation level, it doesn't grab the primary buffer, it locates everything in software, but the one thing it does is take a fairly large secondary buffer (1MB). Being in software shouldn't make this an issue, but I'm betting that your old soundblaster is having difficulties with both DirectSound and DirectShow operating at the same time.
I'm going to try an experiment to work around this one.
OK, here's a test version: http://www.sendspace.com/file/ikte0q
If my theory is correct you'll see the console filling with "EC_COMPLETE" messages when you run a map.
Well,the Test build works great(hoowheee...).
But i get no unusal messages in console,nothing like "ec_complete" or so,only "you got the nails" or "player got eviscerated by a fiend".
Is that good or bad?
Anyway,thanks for your support Man,i mean you could have said "get a decent SoundCard,Idiot" and i wouldn´t blame you for that.
Okay,"EC_Complete" there it is.After approximately 2 minutes in "Masque of the Red Death".
Eventually it didn´t show on my first Test-Run through E1M1 because i went too fast.
Yeah, I just coded it to show when the sound looped. I was guessing that you were getting false EC_COMPLETE messages (which normally indicate that a sound has finished) after 1 or 2 seconds, possibly as a result of something in the K-Lite pack.
I'm curious about why the test build worked though as I had changed nothing else in it. It was just an experiment to see if my guess was right.
Anyway, I have new code that uses a better method for detecting when a sound has finished now so it won't be happening with the next version. :)
All the above have now been fixed in the new 1.8.3c release. ;)
Post a Comment