Crinkelite
-
Posts
26 -
Joined
-
Last visited
Posts posted by Crinkelite
-
-
That's very encouraging guys. I'll get back on it ASAP.
-
Thanks teh_saccade.
It's not really ready to play yet, I'm going to get back to it soon to make it playable and get it working with windows and Xbox controller.
I did play Deadly Shadows on pc with a logitech dual analogue controller many years ago,
I was delighted with the controls but wasn't so happy with the direction the game had taken.
I played The Dark Age with a program called PinnacleGameProfiler which was much better than Xpadder or Joy2key but cost €15 at the time.
I certainly got my money's worth as I managed to play many games adequately with it including STALKER, Morrowind and Doom3.
Anyway, I'd love to play TDM with a controller even though some here might think it sacrilegious.
I'll try to get it to an acceptable state as soon as I have the taffin time.
- 2
-
- Popular Post
- Popular Post
I've been trying to implement dual analogue gamepad support for tdm for many months now.
This is my first real attempt at serious coding so the road has been difficult and slow.
The current state of things can be found at https://github.com/crinkelite, all changes are in the joystick branch.
It depends on SDL2
Right now, it will only work on Linux with a playstation 3 controller.
Please understand this is a complete amateur hack job which probably breaks every rule there is.
The good
---------------------------------------------------------------------------
The players view is controlled by the right analogue stick
Creep/Walk/run speed is controlled by the magnitude of the left stick.
The gamepad buttons are mapable in the bind menu (use the mouse to initiate the bind for now).
---------------------------------------------------------------------------
The bad
---------------------------------------------------------------------------
The cursor can be manipulated with the right analogue stick while in the menus and menu items can be activated with the R1 button.
The approach I took to this is misguided and while it's playable, It needs to be rewritten.
Any joystick button can be set as a shift button (IMPULSE_53), potentially allowing two bindings to be set to one button. eg. ( R2 = jump ) ( SHIFT+R2 = mantle )
The shift button can also act as a Lean modifier, when the button is held the left analogue stick switches from movement to lean control.
This allows the player to lean to the angle given by left analogue stick and the tilt given by it's delta. ( this is barely working. it's very jittery and the trigonometry is not quite correct )
--------------------------------------------------------------------------
The ugly
--------------------------------------------------------------------------
The game crashes if it receives too many analogue inputs while the cpu is busy.
You can avoid this by not pushing the sticks while the game is loading.
I'm working on a fix but it will take some time.
Rotating frobbed items is not yet implemented.
The DPad East/West is somehow getting conflated with the triggers.
Many many other disastrous bugs.
--------------------------------------------------------------------------
I'm going grey(er) trying to get the kinks ironed out so I'm going to draw some attention to it here.
If there's any appetite for controller support maybe someone reading this can help.
Please let me know if I should provide any further information.
TLDR
You can (sort of) play thedarkmod with a playstation controller If you're on Linux.
- 5
-
I would have liked to have provided more help but I'm a complete amateur with no formal training and it seems like every time I tried to write something contributory, I found I was unsure of what I was trying to say or lacking in basic understanding.
For these reasons, I decided to remain silent rather than muddy the waters.
Ok so it seems this issue is a bug that I introduced through editing the code.
I was sure that the bug existed in both my code and the latest SVN revision but this was a mistake.
I had verified this by reverting to, and compiling the svn code and triggering the bug there also.
I'm guessing that I may have had a debugging session open when compiling the SVN code which would have prevented the build script from copying the binaries into the run directory. This allowed me to mistakenly believe that I was running the virgin code when I was in fact running my broken code.
Basically, a stupid blunder that wasted my time and yours.
Please take everything I write in this forum with a massive pinch of salt.
-
Not that I'm an expert on this failure point but we should also get the Darkmod.cfg.
There are a few settings in there that may cause crashing.
Sorry nbohr1more, I missed your post somehow.
I'm pretty sure this isn't a configuration issue but I'll stick the Darkmod.cfg up anyway.
-
A minor point to be sure, but please be careful with the terminology. I know that you're compiling a 32-bit TDM under a 64-bit OS but I want to clearly distinguish that case from the very different case of compiling a 64-bit TDM, which is what your subject line had me assuming initially.
A very valid point. I'll have to see if I can change the title somehow. - EDIT: I can't
This is a very wise choice, IMHO. I've taken a similar (more extensive, in fact) approach, with positive results.
Oh good. I had a nagging feeling that my non-packaged libs could somehow be the cause of this crash so it's good to know that you're not having problems.
Is this happening consistently, literally every time you lean (left, right, forward)?
Is it happening on "The Outpost" (per your log) only or on other missions too?
It happens consistently with "Q", "E" and "F" and on all maps.
I managed to get some slightly more accurate information about the crash.
The assertion fails at cm/CollisionModel_rotate.cpp:1616
assert( ((byte *)&start) < ((byte *)results) || ((byte *)&start) > (((byte *)results) + sizeof( trace_t )) );
I'll have to have a a look tomorrow with fresh eyes.
Thanks to both of you for your replies and sorry for the 64/32 bit ambiguity.
UPDATE:
(gdb) p (byte* )&start $12 = (byte *) 0xffffc304 "w\037\337\302lr\256¨\274\207@\366(\336\302\034\234\257", <incomplete sequence \302>
(gdb) p (byte* )results $13 = (byte *) 0xffffc298 ""
(gdb) p ((byte *)results + sizeof( trace_t )) $14 = (byte *) 0xffffc304 "w\037\337\302lr\256¨\274\207@\366(\336\302\034\234\257", <incomplete sequence \302>
It looks like the first part of the assertion is false because results is empty
The second part of the assertion fails because ((byte*)&start and ((byte *)results + sizeof(trace_t)) are equal.
Anyway, I'll look again tomorrow.
-
I have all my dependencies in place and the game is compiling fine. It produces 32 bit binaries which runs as expected for the most part.
/home/joe/games/tdm/darkmod/thedarkmod.x86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b0a31110c49260cde4db9c3c6e14e32516a44536, not stripped, with debug_info
There is something subtle going awry here. As I've said, the game loads and is playable.
It runs very well in fact but something goes wrong when the game tries to rotate the player model for the lean command.
I'll try to provide more info later and possibly open a bug report. Got to go do some taffing work now.
-
First I'd like to apologise for my lack of contribution in this forum in the last few months
I am grateful to Hamlet and Nightstalker and many others for their efforts to get the linux version compiling and running.
I would have liked to have provided more help but I'm a complete amateur with no formal training and it seems like every time I tried to write something contributory, I found I was unsure of what I was trying to say or lacking in basic understanding.
For these reasons, I decided to remain silent rather than muddy the waters.
Ok with that out of the way I'll explain my current problem.
I'm still having trouble getting things working on 64-bit linux. (Currently -r6775)
It compiles fine but crashes out at runtime with an error which I believe to be something to do with libboost_filesystem.a
I've attached The full gdb session log as `gdb-packaged-libs.log.txt`
After faffing around for days wondering what it could all mean, I decided to obtain the Boost source and compile my own 32 bit libraries.
I placed the files in /usr/lib32/ and made the necessary edits to the scons files.
Miraculously, I had caught a break and the game compiled and ran without issue... Or so I thought.
I've now discovered that pressing the lean key causes the game to crash. I have posted the record of the gdb session in the attached file "gdb-system-libs.log.txt"
A backtrace reveals that a problem develops after the call to idCollisionModelManagerLocal::Rotation() (frame 5)
I have also done an `info args` and an `info locals` to show the state of the data.
Presumably, this data causes the assertion in /usr/lib32/libc.so.6 (frame 4) to fail somehow.
Anyway I've exhausted all avenues that I can think of so please help if you can.
Don't hesitate to ask for more info/testing.
ps. congrats on the steam greenlight thingy.
-
So where is it?
Sorry about the delay but as I indicated earlier, I'm getting the same compilation errors on ubuntu-32 as with archlinux-64
I've actually spent most of the interim wrestling with qemu and installing slackware.
It's not something I'm used to.
I'll post my results if I can manage to get slackware ready for compiling but I hope nobody's holding their breath :/
I'm delighted to see some positive action on the Linux build.
Ubuntu version 4.8.0-30 generic i686
gcc 6.2.0
-
I took a look at your log files but I cannot give any useful advice because the errors you're seeing are completely different than the ones I saw when compiling under Slackware.
But I was reminded that you're trying to compile TDM under a 64-bit OS. In contrast, throughout all of my TDM testing, I've only been compiling and running it on 32-bit Linux (Slackware 13.1 and 14.2), never under 64-bit Linux.
Wish I had more to suggest, but, short of saying "switch to 32-bit Slackware", I don't. Sorry.
Ok so I decided to try compiling under 32 bit Linux.
I installed Ubuntu 32 bit 16.10 via qemu and attempted to compile the source.
I'll post the resulting output later tonight (when I figure out qemu's shared folder feature) but for now I'll just say that the results seem to be identical to 64 bit arch.
Compilation fails with while processing pugixml.hpp with "reference to basic_string is ambiguous".
Is it possible that this bug has been introduced by the pugixml project?
I'll do my best to get the actual logs posted later and will attempt to set up a working Slackware 32-bit environment for further testing.
Thanks to NightStalker for taking the time to look at the logs. I'd like to know what version of Slackware you're using so that I can try to match your environment as closely as possible.
-
could I please get permission to view the beta testing forum.
-
@Crinkelite:
Given that "latest SVN" is a hard target to deal with, if you're willing, can you please try compiling against the "virgin" 2.04 source code?
I'm wondering if you'll encounter exactly the same issues that I do under 32-bit Slackware 14.2 (circa mid-2016, GCC 5.3.0, SCons 2.4.1) or if you'll encounter more and/or other build issues.
I suspect you'll have to apply the 2 patches in this post at some point, but I'd be interested in your results.
No hurry, and no need to do this at all if it's a pain.
And thanks for confirming (in that other thread) that my SCons/Linux patch works for you. For me, it's saving about 7 minutes with each and every simple code change after the 1st large/slow build, so I could/would not live without it.
I get the same results with 2.04 as with the svn.
I've attached both pre and post patch logs.
Thanks for fixing the scons issue. I'm seeing substantial gains also.
I would have liked to reply earlier but I was away for the weekend.
I'm very anxious to see this get fixed so I'm quite willing to do any testing that might help.
-
I think the file is auto generated with default settings if it is not found on startup.
Delete or rename it and launch the program as normal.
- 1
-
I just applied the patch myself and it's working beautifully.
- 1
-
gcc (GCC) 6.2.1 20160830Sconsscript: v2.5.0.rel_2.5.0:3544:95d356f188a3[MODIFIED], 2016/04/09 14:38:50, by bdbaddog on ubuntu1404-32bitengine: v2.5.0.rel_2.5.0:3544:95d356f188a3[MODIFIED], 2016/04/09 14:38:50, by bdbaddog on ubuntu1404-32bitengine path: ['/usr/lib/python2.7/site-packages/SCons']
Good stuff Nightstalker, I too am delighted to talk to another Linux compiler.
I don't know how much help I can be but please let me know if I can assist in any way.
-
Your efforts would be highly appreciated NightStalker. I've been wanting to get this compiled on linux for years now. I lack the skills fix the errors I get.
Forum post:
http://forums.thedarkmod.com/topic/18318-compilation-error-reference-to-basic-string-is-ambiguous/
Bug report:
http://bugs.thedarkmod.com/view.php?id=4419
My system:Linux 4.8.11-1-ARCH #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016 x86_64 GNU/LinuxPlease contact me if I can help in any way. -
Are you sure you're on the latest drivers? I have a GeForce GTX 660 and I'm on 375.20-1
They're the latest binaries from the Archlinux repositories.
-
Hello freyk
Thanks for the reply, I'm not having an problem connecting the controller.
The problem is that there doesn't appear to be any code in darkmod to handle joystick input.
The same is true of dhewm3 but I managed to cludge some code in to handle it.
I can now play doom3 with my dualshock3 (although without being able to navigate the gui.)
I'd like to compile darkmod with this extra functionality but I've never been able to compile the bloody thing.
I'm tempted to open a bug report on the svn but I'm pretty sure I'm the only one having this issue and I don't want to hinder the good work with something that is quite possibly a problem with my system alone.
I'd also to offer my modest skills to help with the coding effort.
-
I'm bumping this as I'm still having this problem.
I've managed to get dhewm3 to working with my ps3 controller and I'd love to have a crack at implementing it with darkmod.
Please help if you can
In file included from game/Missions/MissionManager.h:28:0, from game/Missions/MissionDB.cpp:27: game/Missions/../pugixml/pugixml.hpp:97:10: error: reference to ‘basic_string’ is ambiguous typedef std::basic_string<PUGIXML_CHAR, std::char_traits<PUGIXML_CHAR>, std::allocator<PUGIXML_CHAR> > string_t;
I'm on build 6675 from the svn repo.
log: https://ptpb.pw/OEAU
-
I'm getting a compilation error on Archlinux x86_64game/Shop/../Missions/../pugixml/pugixml.hpp:1071:2: error: reference to 'basic_string' is ambiguousLinux 4.7.2-1-ARCH #1 SMP PREEMPT Sat Aug 20 23:02:56 CEST 2016 GNU/Linux
-
this texture, and many others are suposed to be at
/saintlucia/textures/darkmod/carpet/rugs/ornate_red_tan01
according to the .mtr file
however there are only three textures and their corresponding .tga files are in the folder, all of which are working correctley in DR.
there is only one .tga file in the
C:\games\Doom3\thiefs_den\textures\darkmod\carpet\rugs
folder and there are no textures. ~I must be doing something wrong because the thiefs den level is playing correctly and displaying all textures.
sorry I couldn't get back to you earlier, I'm kind of busy with college.
-
Hi again, so i did as Jesps suggested and followed the instructions proided in his link. tha installed the game correctley and i was able to play the thief's dem map without problems.
However I was still only seeing the same models and resources that I had in the first place (didn't have the door that is used in the tutorial)
so I did as Fidcal suggested and extracted the Thief_den.pk4 into the st.lucia directory I was asked to ver write some files which i declined to do as they were the same size and name. this enabled me to open the thiefs den map in DR and also provided more models.
(insidently not the door that is used in the tutorial but thats ok).
problem is though, about half of the textures in the media browser are still reporting
'shader not found' in the preview window and do not apear when used in a compiled map.
I guess I can continue just using the textures that are working so there's no real problem for now but I'de like to get to the bottom of it.
thank you both for your help.
-
You guys are on the ball!
-
I've already stated how impressed i am somewhere else on the forum but I may as well abreviate it here.
YOU GUYS ROCK. YOU ARE GOING TO MAKE A LOT OF PEOPLE VERY VERY HAPPY.
One or two suggestions. bear in mind these are only suggestions. I realise that you have been working very hard and cannot implement the whims of every excited fan.
one of my favorite things about thief 1 and 2 was the sword fighting. the way the guards took you on in a fencing stance, leading with their sword arm in a side profile and taking those wide crabwalk steps at you. the strange mix of comedy and realism is priceless. I don't know if this is practical in the Doom 3 but I live in hope.
My other suggestion I think may be easier to imlpement but might not be to everyone's taste. I think it would add to the game if you were unable to run backwards or in a side strafe (only forwards and diagonaly forwards). I think this would heighten the suspense and risk of running at full pace from one dark corner to the next as you are unable to keep an eye on the murauding maniacs behinds you. this also fits nicely with the real world. lets face it you would never run backwards down stairs.
that said I'de like to commend you on the great work you've done on manteling, rope arrows, AI scripting, modeling, textures, light sources, The DarkRadiant, voice acting, frobing ect... the list is endless. The doom3 engine is almost unrecognisable. Keep up the good work I have enormous faith in this and I hope it enjoys the same lifespan as all the thief titles.
No rendering on screen (and no way to fix it without accessing newer assets)
in TDM Tech Support
Posted
I'm having the same issue, where do I place the files from the glprocs.zip?