Jump to content
COMBATSIM Forum

Recommended Posts

9 hours ago, DrKevDog said:

Any additional edits need to be made?

 

No, this should be enough.

 

I’ll try to do more Windows 7 testing. I did notice the memory managers being slightly different (so that some errors only surface on Windows 10) and that’s my best guess for your crashes right now.

Link to post
Share on other sites
  • Replies 302
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I tested on Windows 7 32-bit with all heap checks enabled, stack randomization, all available debug runtimes.

 

I did find a small error with my Intel integrated driver failing to render a specific contrail, but it’s non-critical. Everything else worked with EF2000 and TAW.

 

The one thing I didn’t test is joysticks. Going to try this later (need to check out how to connect my periphery to the machine in the first place).

 

I.e. sorry, no progress …

Link to post
Share on other sites

Not sure how welcome a feature request will be, but here goes: :)

 

I'd like to be able to specify the map and palette combination manually, or maybe a map then a series of palettes that can be cycled by SHIFT+S with the current palette name at the bottom of the screen.

It would be fine to specify the maps and palettes via a text file, but that kind of negates the reason to have a GUI...

Link to post
Share on other sites
13 hours ago, mikew said:

Not sure how welcome a feature request will be, but here goes: :)

 

I'd like to be able to specify the map and palette combination manually, or maybe a map then a series of palettes that can be cycled by SHIFT+S with the current palette name at the bottom of the screen.

It would be fine to specify the maps and palettes via a text file, but that kind of negates the reason to have a GUI...

 

I absolutely want that as well. The palettes being hard-coded is totally wrong.

 

But I want to solve this via loading the EF2000/TAW mission files. This should give us the ability to specify our own palettes, while also having access to actual EF2000/TAW missions, and being able to back-port the palette mods to the original EF2000/TAW.

 

But I’m on code freeze for new TFX code right now. I will only add another parser after the current mess has been cleaned up and TFXplorer is in a releasable state.

 

(The goals I’m currently pursuing are

  1. make the lost worlds of TAW/EF2000 accessible without having to edit game.cfg and reading the long manual on my website – I don’t think a single person besides us here has ever done that
  2. this requires adding a GUI, which is overdue anyway (and it gets harder with every line of code we add to the simulation core accessing the message loop directly)
  3. establish a proper API for extensions

… new TFX modding facilities will come after that.)

Link to post
Share on other sites
  • 4 weeks later...
  • 3 weeks later...

Mike, regarding your Joystick problems:

 

On 1/24/2019 at 9:32 PM, mikew said:

It's a while since I wrote that, but yes, things have changed....and generally for the better.

The x64 version seems to work OK now, and the joystick is indeed recognised:
 


found HID "SDL Madcatz Mad Catz V.1 Stick"
  axis 0130 (0007): -32768-32767
  axis 0131 (0008): -32768-32767
  axis 0132 (0009): -32768-32767
  axis 0135 (000A): -32768-32767
  axis 0139 (000B): 0-8
  button 0901 (0000)
  button 0902 (0001)
  button 0903 (0002)
  button 0904 (0003)
  button 0905 (0004)
  button 0906 (0005)
  button 0907 (0006)


did1st.dat not opened; no patches will be considered

trying to load .dat file ...
identified an F-22 Total Air War .dat file
loading .dat directory
loading 19 directory names
loading 19 file extensions
extracting 10438 files
.dat loaded successfully


Direct3D 9 (SDK version 32)
trying to create GPU context (8x AA, windowed, pure hardware T&L)
16x anisotropic filtering selected
missing 3\BALL_3.3

but for some reason it still doesn't work, although if the joystick is plugged in the arrow keys don't work either for control.

At least I can I can start the engines now as long as I have a US keyboard selected.

 

The game.cfg was missing, so I created one with a single entry 'CONTROL=1' but that has no effect.

Maybe it needs some other parameter?

 

 

On 1/26/2019 at 2:47 PM, mikew said:

I've had another look and while the joystick is found, it doesn't do anything in TFXplorer except disabling the arrow keys.

The joystick works fine with TAW which also uses Wine.

 

Running TFXplorer after TAW just highlights how wonderful the TFXplorer rendering is. If only the two could be combined...

 

The only problem left with running TAW in Wine without changing the default settings is how the 2D windows are handled.

Once flying around in dgVoodoo, I haven't run into any stability problems, but pressing the 'Del' key to see the map usually results in a crash.

 

One new experience with TFXplorer is having the plane spontaneously explode. I don't recall seeing that before.

All I can do afterwards is F12 Smartview to toggle between the bits of debris.

 

Someone landed this an hour ago: https://source.winehq.org/git/wine.git/commit/3a9edf9aad43c3e8ba724571da5381f821f1dc56

“user32: Implement GetRawInputBuffer. CoD: WWII uses it to read mouse motion instead of listening to WM_INPUT messages.”

 

This is a function TFXplorer uses for joystick input; it being unimplemented would explain the dead joystick. I’ve gotten a lot of feedback for a tutorial I once wrote on the RawInput API; maybe someone from the Call of Duty team has read it, implemented it, and this finally caused Wine to emulate TFXplorer properly :D

Link to post
Share on other sites
  • 2 weeks later...

I found another memory corruption related to joystick handling. It may be related to DKD’s crashes, so I hope that an upcoming version will finally work on his system.

 

I found the bug after I noticed that TFXplorer crashed whenever my USB headset was attached. It was related to the number of buttons and axes on USB devices. TFXplorer recognizes my headset as an input device, so I can now use my its volume knob as throttle :D

 

Error messages during loading are now printed to the loading screen instead of the console, which makes a lot more sense. Nested error messages are the hell to program, but I regard them as absolutely necessary.

2020-07-14%20error%20output.png

 

Multi-line messages are not yet supported, so read each line as:

Quote

 

Error: The system cannot find the path specified.

while loading 3\FOO.3

while loading ss\ssinfo.fn [line number yet to come].

 

 

Link to post
Share on other sites

So, is there a new build for us?

 

I think the problem is definitely USB device related as I was getting DKD-esque crashes until I disconnected the USB keyboard and connected it again.

Link to post
Share on other sites

Wow, I forgot that I automated the deployment – one click and a new version is built and packaged! You’ll get an updated version today after all :)

 

http://krishty.com/taw/tfxplorer/2020-07-15/TFXplorer.7z

 

DID.DAT is no longer extracted entirely at startup (this would be nuts with TAW, ADF, and EF2000 in parallel). All files are now extracted on-demand.

 

Makes the loading time so quick I can’t read the errors any more. Should I add another button after loading the scenario but before starting it so we can examine the error log?

Link to post
Share on other sites

Maybe a logfile saved where the game exe is located?

 

Seems to work for TFX3, although I don't have a joystick right now.

I'm not seeing any TFX2 scenarios though.

Link to post
Share on other sites

Forgot the changelog …

  • moved some errors and warnings during loading from the console to the scenario loading screen
  • removed legacy settings “LEVEL” and “SEAWORLD” from game.cfg
  • GUI uses the accent color more often
  • fixed crash with HID handling
  • fixed keyboard navigation
  • fixed focus during page transitions
  • fixed smooth scrolling, accent color, and dark theme scrollbars with 32-bit TFXplorer
  • fixed page transition not rendering the new page correctly
  • fixed scroll bars not rendering correctly
  • fixed wrong error message with game.cfg in 32-bit builds
  • fixed button spacing and color
  • minor performance improvements (reduced stack memory demand, improved compiler settings, …)

 

5 minutes ago, mikew said:

Maybe a logfile saved where the game exe is located?

Yes, that’s on the TODO!

 

6 minutes ago, mikew said:

I'm not seeing any TFX2 scenarios though.

Registry keys set properly (according to

?)

Link to post
Share on other sites

For some reason the registry keys didn't match the directory structure. I didn't check that since it was working before and I don't remember changing anything.

Anyway, TFX2 is back now. :)

 

An observation...

Right now, I don't have a joystick connected so am using the arrow keys to control the plane.

If I'm flying level, then hold the up or down arrows to change pitch, the display update rate becomes quite jerky after a second or so and returns to normal a second or so after I release the key. This probably isn't anything new, but I haven't noticed it before.

EDIT: That was with Win10. The effect is not so pronounced on Linux.

Link to post
Share on other sites
9 hours ago, mikew said:

An observation...

Right now, I don't have a joystick connected so am using the arrow keys to control the plane.

If I'm flying level, then hold the up or down arrows to change pitch, the display update rate becomes quite jerky after a second or so and returns to normal a second or so after I release the key. This probably isn't anything new, but I haven't noticed it before.

EDIT: That was with Win10. The effect is not so pronounced on Linux.

Interesting – I didn’t notice anything like this here. I’ll investigate …

 

Edit: Could it have to do with the wingtip vortices? The slowdown seems to kick in whenever wingtip vortices form, and it seems to stop when they also stop forming. Can you confirm this?

 

Edit 2: Oh, it’s the error list. When the game starts, the error list is off-screen and still has input focus. Whenever you press the up/down arrow keys, it tries to scroll, causing Windows to redraw the scroll bar. The scroll bar drawing (GDI) interferes badly with the game drawing (Direct3D), hence the stuttering. Will be fixed in the next version.

Link to post
Share on other sites

You found something! I was about to put it down to running at 4k resolution with inbuilt Intel graphics.

That would explain why I don't see the same effect in roll with the left and right keys.

Link to post
Share on other sites
16 minutes ago, mikew said:

That would explain why I don't see the same effect in roll with the left and right keys.

 

Yes, I was perplexed. This is the kind of error you don’t want to investigate.

 

I used a profiler and went far out of terrain bounds so that the terrain rendering did not clutter the performance graph. And suddenly … 13% of time spent calling scroll bar functions – this just had to be wrong :)

Link to post
Share on other sites

The old splash screen is gone; long live the new splash screen.

 

2020-07-18%20new%20splash%20screen.gif

(Splash screen slowed down for the video; it’s loaded in a split second actually.)

 

You only have to click Accept if there are any errors; it forwards right to the main menu otherwise.

 

The DirectX runtime dialog is gone. The one-second delay after starting TFXplorer is gone. Single-threaded initialization is gone. Obscure console output is gone.

 

The error handling still needs refinement, but this had to be done anyway. I’m just glad we’re getting closer to a GUI which could actually be shipped with a game … and the startup has become real quick.

Link to post
Share on other sites
On 6/30/2020 at 10:14 PM, Krycztij said:

Someone landed this an hour ago: https://source.winehq.org/git/wine.git/commit/3a9edf9aad43c3e8ba724571da5381f821f1dc56

“user32: Implement GetRawInputBuffer. CoD: WWII uses it to read mouse motion instead of listening to WM_INPUT messages.”

 

This is a function TFXplorer uses for joystick input; it being unimplemented would explain the dead joystick. I’ve gotten a lot of feedback for a tutorial I once wrote on the RawInput API; maybe someone from the Call of Duty team has read it, implemented it, and this finally caused Wine to emulate TFXplorer properly 

I'm not sure if that made to Wine 5.12, but they've definitely been messing around with the control stuff because now the keyboard and mouse don't work with TFXplorer either.

... and the graphics are totally screwed up in the x86 version. :(

Link to post
Share on other sites

I’m overhauling the input handling and adding an option page with test facilities and debug information. We’ll find out what goes wrong, but (like every time) it’s a little bigger than I anticipated in 2012 :)

Link to post
Share on other sites

I think we already know that Wine hasn't implemented the input method that you're using for the joystick.

Your programs usually work quite well in Linux, even with zero special configuration as I just double-click on the exe.

 

Wine is not really a viable Windows replacement though as I get some serious lockups (that require holding the power button down for 5 seconds) with some games. No doubt it's possible to find out why that happens for a particular game, but it would be a time consuming process.

This is somewhat irritating as I only normally reboot Linux every couple of months or so.

 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...