![]() |
![]() |
#1 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
HODE warpos
Heart Of Darkness Engine.
Give it a try: I have it working with WinUAE warpos, but could not work as supposed to be for other environments (wrong colors, etc). Needs all *_hod. files and hod.paf from original game or demo files inside a DATA dir. Of course thanks to "Modern Vintage Gamer" for the release of the XBOX SDL1 source. ![]() Upgrade beta6: Last edited by Cowcat; 22 February 2021 at 15:49. |
![]() |
![]() |
#2 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 3,006
|
Works pretty well! Played in a window on 16bpp LE Workbench with a joystick for a while on Ragnarok/Voodoo3 system. Did get a crash at exit, sonnetlib complaining PPC Memory List Corruption Detected and it threw an exception.
|
![]() |
![]() |
#3 |
Moderator
Join Date: Jan 2002
Location: Chicago, IL
Posts: 3,454
|
Cool news, I’ll try it.
|
![]() |
![]() |
#4 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 3,006
|
One issue I've noticed is that regardless of the scaler setting it seems to want a window or a screen at 800x600 the extra space is just black. Would be nice if XBR mode did not require 32bpp but that seems what is set in the original source, don't know if that would be easy to fix.
Last edited by grelbfarlk; 16 April 2020 at 03:33. |
![]() |
![]() |
#5 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
@grelbfarlk Good that it works for 98% systems out there.
What I know: - It crashes on exit. - The extra black spaces. - Hardcoded to 800x600 and 16 bpp. - Path directory is hardcoded to DATA (no config file is re-created): Use provided hode.ini to change fullscreen or other settings. - Thought XBR mode worked, but it turned out only on earlier versions: Needed to cheat the code with a 16bit screen AND 32 bit surface with 16 bit masking. 32/32 was too slow for normal systems. 16/16 gives a mangled display, so what the hell..... Last edited by Cowcat; 16 April 2020 at 12:20. |
![]() |
![]() |
#6 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,064
|
Seems to work nicely and fast on my Ragnarok with Radeon 9200.
|
![]() |
![]() |
#7 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 3,006
|
|
![]() |
![]() |
#8 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,064
|
It crashes on exit, yes.
|
![]() |
![]() |
#9 | ||
Registered User
Join Date: Sep 2011
Location: ItAlien
Posts: 171
|
This is the exception thrown on my machine:
Quote:
Quote:
![]() |
||
![]() |
![]() |
#10 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
@funK
Try to downgrade scale_factor on hode.ini (just to test what happens, even with large black space) and of course fullscreen. 800x600 is what it is in source. Not sure about other resolutions or if game data is set internally to work with other dimensions. I tested it a little with it but not a firm sucess. Also another hack to set 8 bit depth could be interesting if I find how to do it. The end crashes and enforcer hits I don't know: They don't happen running in morphos emulation so I don't know what to look for. Edit: Actually setting game to 512x384 (in source) and scale factor of 2 gives a screen with no black borders. Game base resolution is 256x192 so multiply for 2 and you have an feasible amiga screen. It explains why 800x600 or other resolutions have black borders because no rescaling is done for screen dimensions by the engine or SDL1 .... So.... Last edited by Cowcat; 20 April 2020 at 19:13. |
![]() |
![]() |
#11 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
New beta above with added "width" value in .ini file.
For low systems set it to "512" if you got 512x384 screenmode (game fits perfectly to full display too). Other width's could be possible but depends of scale_factor. xbr algorithm working now. |
![]() |
![]() |
#12 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 3,006
|
Did a quick test on beta 2. With scaler set to 2 and 512 width, XBR works fine on in a window on 16bpp Workbench. Fullscreen works correct as well. Still crash on exiteverything I've been trying to build lately is doing this too so, let me know how you fix it..
Last edited by grelbfarlk; 21 April 2020 at 22:38. |
![]() |
![]() |
#13 | ||
Registered User
Join Date: Sep 2011
Location: ItAlien
Posts: 171
|
Quote:
![]() Enforcer hits are still there on startup and game still crashes on exit, and I also noticed there's following warning thrown many times with different values, especially during the intro but sometimes also in-game: Quote:
|
||
![]() |
![]() |
#14 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
@funK
Technically a 320x240 fullscreen should suffice (with black surroundings). About 512x384 fullscreen, that's something I had years ago for Blitzquake with a BlizzardVision: Can't check it with WinUAE warpos emu as Picasso drivers don't have this resolution but 640 is the closest. BTW 512x384 has scale factor fixed to 2 (can't be changed). And well, a 2.5 scale_factor (256x192) sets 640x480, but the engine uses integer values, so is not possible now. The buffer underruns also happens for whatever system used (debian for example). There's a value to test: max_active_sounds. Now news for hits/end crash.... |
![]() |
![]() |
#15 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
Updated to 0.2.9.
Beware of old setup.cfg (where game is saved) as the filesystem behaviour is changed: Now resides on root game dir, not on DATA dir. Better to backup it and put it in new place as only one should exist. |
![]() |
![]() |
#16 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 3,006
|
Beta3 works, has the same crash on exit, which seems to throw the same exception at SRR0 as an application I just built. HOD and my app crash and set SRR0 at the same address, dumping the memory 0x1000+- have the exact same output via VDAPPC. So whatever it is it's common between our two programs.
Attached vdappc output from SRR0: +-1000. Code:
Task name: 'fbasdlppcx_PPC' Task address: 69DE91A0 Exception: Program SRR0: 68485B5C SRR1: 0008F030 MSR: 00003030 HID0: 0000C0A4 PVR: 70000203 DAR: 08E13D40 DSISR: 40000000 SDR1: 17E0001F DEC: 00079FC7 TBU: 00000000 TBL: 2D2D8452 XER: 20000000 CR: 44000484 FPSCR: 82002000 LR: 68485C38 CTR: 00000000 R0-R3: 454D454D 69EA8E40 6000FFFF 7FDFFA88 IBAT0: 0000003E 00000002 R4-R7: 69C81300 00000000 00000060 0000007F IBAT1: 620003FF C2000002 R8-R11: 69C00000 69940000 69C00000 69940000 IBAT2: 6820003F 00200002 R12-R15: 68DB9A90 69EA8F44 00000000 00000000 IBAT3: 00000000 00000000 R16-R19: 00000000 00000000 00000000 00000000 DBAT0: 0000003E 00000002 R20-R23: 00000000 00000000 F8007FFF 00007FFF DBAT1: 620003FF C2000042 R24-R27: FFFFFFFF F8007FFF 68E2E8A0 69C89420 DBAT2: 6820003F 00200022 R28-R31: 69C88FC0 69C81300 69C89420 00000058 DBAT3: 00000000 00000000 Last edited by grelbfarlk; 11 May 2020 at 03:40. |
![]() |
![]() |
#17 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
@grelbfark Yep, I know. Kinda of what it happens with Devilutionx too and others. I suspect that crashes happen using certain posix functions not being freed at exit.
|
![]() |
![]() |
#18 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,064
|
Nothing has changed in both libraries for more than two years now. Other SDL compiled stuff do not seem to be affected. I recommend not using atexit().
You didn't show the requester that popped up stating this is a memory error. It is either memory corruption detected during freeing memory or memory freed twice. |
![]() |
![]() |
#19 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 772
|
@hedeon AFAIK there's no atexit problem, because there's none in the program. SDL is another case to check: Sometimes game can be closed but get system unstable.
|
![]() |
![]() |
#20 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,064
|
If that was checked on either MOS or UAE then it does not count.
|
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
RTCW for Warpos | Cowcat | Coders. Releases | 67 | 18 June 2024 19:10 |
OWB WarpOS possible ? | drluking | support.Apps | 10 | 29 November 2021 19:54 |
GLHexen2 Warpos. | Cowcat | Coders. General | 84 | 01 July 2021 22:29 |
UAE for WarpOS 0.8.12 | grelbfarlk | request.Apps | 0 | 23 November 2016 01:14 |
WarpOS Programming Help? | esc | support.Other | 8 | 21 October 2015 10:37 |
|
|