Duke4.net Forums: XL engine will supports Shadow Warrior(Classic). - Duke4.net Forums

Jump to content

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

XL engine will supports Shadow Warrior(Classic).  "It's NOT dead."

User is offline   Player Lin 

#1

When wandering around about some information of Daggerfall in UESP.net, I accidentally clicked the link of DaggerXL and visited the XL engine site, and then I found the site started did updated since late of last year...

In the latest update post in its blog, it said XL engine will not only supported Blood, but also Shadow Warrior (Classic) too. :dukeaffirmative:

http://xlengine.com/...ngine-update-3/

Yeah, it still just some screenshots without actual footages...but looks ok I guess...

Looks like we will have other good port of Build engine games if it goes better and not dead again... :)
2

User is offline   Kyanos 

#2

Very cool, pleasantly surprised to see the XL engine is still progressing.

quote from the link:

Quote

In fact Shadow Warrior is 100% playable, including sound, music, controls, memory management and so on in the engine and has been for a month or two.
So why play Shadow Warrior using the XL Engine instead of an existing port? Honestly there aren’t really any compelling reasons, the existing ports do a great job. Of course I plan on changing this with future releases and in the future there will be more reasons to play Shadow Warrior on the XL Engine.

0

User is offline   Hendricks266 

  • Weaponized Autism

  #3

Recently I've begun to think that it's better to construct criticism by showing rather than telling, so for now I will simply say this: Without using the Build Engine and Apogee Sound System, either directly or through exact reimplementation of their algorithms, any such project will never be anything more than an approximation, no matter how flashy.

I hope I can show more soon.
3

User is offline   HulkNukem 

#4

I so want to play Outlaws on a newer/more supported engine. It is such a clusterfuck to get running, and everything always controls less than ideal in the end.
Blood has had many attempts, and I forget which version I have (i believe it uses Eduke) its outdated and afaik it wasn't being updated anymore (its not BloodCM). It was a cool port and was mostly finished, certain things were still buggy as hell and episode 3 and 4 barely worked and were labelled as beta. Fact is though this was more fun to play than trying to get the original Outlaws to work.
WHERE ARE YOU MARSHALL???
0

User is offline   Lunick 

  • Snazzy Ex Tazzy

#5

Outlaws is actually very behind in this project as they don't have a debugger for it since it is a Windows game so expect to see the other projects more than Outlaws (it's why it hasn't been mentioned lately)
0

User is offline   Hendricks266 

  • Weaponized Autism

  #6

View PostLunick, on 15 February 2016 - 11:52 AM, said:

Outlaws is actually very behind in this project as they don't have a debugger for it since it is a Windows game

WTF? Does Lucius even GDB?
0

User is offline   Lunick 

  • Snazzy Ex Tazzy

#7


5

User is offline   Striker 

  • Auramancer

#8

View PostLunick, on 15 February 2016 - 05:13 PM, said:



So, the implementation of Shadow Warrior is pretty much spot-on. Good thing.
0

User is offline   Robman 

  • Asswhipe [sic]

#9

Well, my interest is piqued, I wonder if multiplayer works.

Is this some kind of "competition" for the eduke engine? I wonder what the main differences are.
Excuse me if I sound uninformed about this project, just hearing about it now.

It's pretty sweet to have something new in the SW world.
0

User is offline   Player Lin 

#10

It looks like nothing too special, but runs in high resolution and no obviously problems...

And I don't think they have a proper MP on XL engine yet(before Beta 5 as its blog said). :dukeaffirmative:


EDIT : I wonder if eduke32 will ever try to add features of OpenGL 4.x, just like GZDooM 2.x branch?

This post has been edited by Player Lin: 15 February 2016 - 10:11 PM

0

User is offline   deuxsonic 

#11

I thought JFSW was excellent when it was being maintained over a decade ago, and SWP does a pretty good job (probably the most advanced of the Shadow Warrior source ports), but SWP in itself hasn't been updated in like 5 years and things I look for in source ports now like supporting music as files and more advanced texture filtering options it lacks entirely. If they're both dead it would be nice to see another port emerge that can take what has already been done and keep going.
0

User is offline   Player Lin 

#12

I just hope esw32(?) can happens too. :dukeaffirmative:

This post has been edited by Player Lin: 17 February 2016 - 06:45 AM

2

User is offline   MetHy 

#13

*yawn*

I still don't understand people's interest for recreations. No matter how "accurate" it is due to the way it's made. I mean, I can understand why someone would interested in creating something like this, but not why one would want to play it over the actual game.

I mean, for Blood, I can 'understand' where the interest comes from since the game demands good hardware in DOSbox and it doesn't have any sourceport. But Shadow Warrior? Anyone can play it fine in high-res in DOSbox and it has 3 sourceports already. Sure, none of them are perfect, but still better than using another engine altogether.

And this is why we need SW32.

...and I need to finish my SW map.

This post has been edited by MetHy: 17 February 2016 - 11:58 AM

1

User is offline   Forge 

  • Speaker of the Outhouse

#14

View PostMetHy, on 17 February 2016 - 11:58 AM, said:

*yawn*

I mean, for Blood, I can 'understand' .... But Shadow Warrior?

apparently SW because:

"When working with the Blood code, one of the things I wanted to do was match up the decompiled source with the Build source in order to reduce the amount of work I had to do. I realized, however, that for best results I should test the Build source integration with something working and complete. So to that end, I added the first – and currently only – game that uses the original source code: Shadow Warrior. The purpose of this integration was as follows:
* Get something working with Build in the XL Engine.

* Start refactoring the code and getting it ready for Blood.

* Test the XL Engine functionality, including game life cycle, XL Engine services, sound, input and other systems.

* Have a complete experience to test with the engine and UI.

* Test the performance and memory usage with a complete game running
."

At least he didn't use Duke3D source codes. It's nice that he's doing blood. Hope he considers redneck rampage as well.

This post has been edited by Forge: 17 February 2016 - 01:54 PM

2

User is offline   Mark 

#15

View PostMetHy, on 17 February 2016 - 11:58 AM, said:

*yawn*

I still don't understand people's interest for recreations. No matter how "accurate" it is due to the way it's made. I mean, I can understand why someone would interested in creating something like this, but not why one would want to play it over the actual game.

I mean, for Blood, I can 'understand' where the interest comes from since the game demands good hardware in DOSbox and it doesn't have any sourceport. But Shadow Warrior? Anyone can play it fine in high-res in DOSbox and it has 3 sourceports already. Sure, none of them are perfect, but still better than using another engine altogether.

And this is why we need SW32.

...and I need to finish my SW map.

After using Mapster for a few years now I would never go back to Dosbox or the original Build editor. Thats why a port is a good thing. Easier to create new stuff for. Easier to play. Not to mention the ability to have highres assets which I am a huge fan of. I'm sure I speak for a lot of people that want to experience more than just the same old game from the 90's if they choose to.

This post has been edited by Mark.: 17 February 2016 - 02:14 PM

0

#16

View PostMetHy, on 17 February 2016 - 11:58 AM, said:

But Shadow Warrior? Anyone can play it fine in high-res in DOSbox


???


View PostMetHy, on 17 February 2016 - 11:58 AM, said:

and it has 3 sourceports already. Sure, none of them are perfect, but still better than using another engine altogether.


EDuke32 is "another engine" already. It's a vastly bugfixed version of Build with modern feature support. EDuke was the equivalent of Boom in the Doom world, except it added code to do a lot of different things, and EDuke32 built upon that.

It's like saying ZDoom is the same engine as vanilla Doom when it's obviously a far cry from that and much modified.

XL probably won't be faithful to the tiniest detail, but if it gets the feel right, who cares? Anything but an outdated source port no longer maintained by its creator, please.
0

User is offline   MrFlibble 

#17

View PostHendricks266, on 15 February 2016 - 10:14 AM, said:

Recently I've begun to think that it's better to construct criticism by showing rather than telling, so for now I will simply say this: Without using the Build Engine and Apogee Sound System, either directly or through exact reimplementation of their algorithms, any such project will never be anything more than an approximation, no matter how flashy.

I've been following the XL Engine project for a while, and the development gradually shifted from attempts to recreate the respective games from scratch (which indeed can never be anything more than an approximation) to full-scale reverse-engineering of each game. I think this originated from partial analysis of Daggerfall to clarify certain game mechanics (that game has many things which are nigh impossible to recreate without digging in the executable). Recently luciusDXL posted a lengthy explanation of what he's doing (and already done). It's a bit too techy for me, but I guess you programming guys will know what's been going on.

The implementation of Shadow Warrior, which is a direct source port and not engine recreation, is related to the development of the Blood part. I guess that SW was chosen because it uses voxels, but I can't be sure.

Currently, the XL Engine forums are the most up-to-date and comprehensive source of information about the project's progress, although some stuff also gets posted in the blog too.

This post has been edited by MrFlibble: 18 February 2016 - 03:31 AM

0

User is offline   MetHy 

#18

Aren't SW's Build and Blood's Build completely different anyway? We're not talking Doom-to-Heretic closeness here, they're pretty far off from each other.

View PostDuke of Hazzard, on 17 February 2016 - 08:19 PM, said:

???



What's not to understand?

Quote

EDuke32 is "another engine" already. It's a vastly bugfixed version of Build with modern feature support. EDuke was the equivalent of Boom in the Doom world, except it added code to do a lot of different things, and EDuke32 built upon that.

It's like saying ZDoom is the same engine as vanilla Doom when it's obviously a far cry from that and much modified.

XL probably won't be faithful to the tiniest detail, but if it gets the feel right, who cares? Anything but an outdated source port no longer maintained by its creator, please.


I could understand a non-fan playing something like XL Engine, but being on this forum, I thought you guys would have a better standard. "It gets the feel" just isn't enough for me.
I know how different EDuke32 is, but it's still built directly on the original Build, original game's sourcecode. No matter how much "reverse engineering you put into it, XL Engine games are still just recreations in another engine.
You have the choice between "original game" and "recreation of original game", why would you choose the later, especially in the case of SW where the original plays perfectly already? Things like "widescreen support", etc, aren't an argument for me, because you're just not talking about the same game.

Oh hey I have all the Michael Jackson CDs here but instead I'll listen to some fan's cover in .flac because it covers as much bass and treble as a vinyl.

This post has been edited by MetHy: 18 February 2016 - 06:19 AM

0

User is offline   Forge 

  • Speaker of the Outhouse

#19

View PostMetHy, on 18 February 2016 - 06:12 AM, said:

Aren't SW's Build and Blood's Build completely different anyway? We're not talking Doom-to-Heretic closeness here, they're pretty far off from each other.

I could understand a non-fan playing something like XL Engine, but being on this forum, I thought you guys would have a better standard.

i can understand your single-minded godzilla stomping about playing SW with 'just another port', or playing a recreation, but you seem to be pig-headed as to why it was done.
It was the test subject. He needed a build game he had access to the source code - 1. get his engine working with a build game. 2. Compare source code to decompiled code.-same, similar, different, it's still a starting point.

Looking at the project and checking out the latest download, a person still needs the original game files in order to use this front-end. And that's what it appears to be, a port, not a recreation.

This post has been edited by Forge: 18 February 2016 - 06:49 AM

0

User is offline   Player Lin 

#20

You know...if luciusDXL(author of XL engine) was not explained those tech shit about XL engine or I just didn't check/don't care his recently blog posts, then I won't posted this thread on here at all. :dukeaffirmative:

This post has been edited by Player Lin: 18 February 2016 - 07:07 AM

0

User is offline   Forge 

  • Speaker of the Outhouse

#21

Posting this info to a thread is fine, imo.
It's interesting to see someone still trying to port those old 90s FPS's (rpg).
I loosely follow the progress of that XL engine just to see where it gets with Blood & if he plans to add more build games.

Some people just like complaining. JonoF's JFDuke3D port was probably blasphemy to them & eduke was "just another Duke3D port"
0

User is offline   MrFlibble 

#22

I'm not sure why the implementation of Shadow Warrior in XL Engine seems to be causing controversy here - it's a source port which was added more for technical reasons than anything else at this moment - but concerning engine recreations based on reverse engineering of original executables I can tell you the following.

A while ago a team of enthusiasts successfully reverse-engineered Dune II. The result, called OpenDUNE, is not only an accurate recreation of the game's code - meaning that all playing mechanics are the same as in the original - but it also allowed to pinpoint and fix some of the issues in the original DOS executables (via this unofficial patch). The code was bug-fixed and then used as a basis for a number of ports, including Dune Dynasty.

While the release of OpenDUNE may not have been a huge event for the gaming community on the whole, it is a solid proof of concept that accurate recreation of game code from executables is possible. Of course, the work with Dune II was somewhat simplified by the fact that this is a real mode DOS programme, but luciusDXL's efforts are clearly in the same vein.

With Daggerfall's source code apparently lost by Bethesda, a reverse-engineered recreation is the next best thing we can get. It's certainly better than any recreation that is based on simply observing how the game works, without checking its executable's internals.

Here's how luciusDXL describes the intended functionality of the XL Engine project:

Quote

The XL Engine will control execution and provide services to the supported games which are run from dynamic libraries - henceforth referred to as DLLs - though they are called different things on different OSs (like plugins). The XL Engine itself will handle everything OS and hardware related, file system, input, graphics output, sound output, etc.. Initially the game DLLs will implement all of the core game code - from sound system to rendering and gameplay - but will use XL Engine services for allocating memory, playing the resulting sounds, blitting the framebuffers to the screen and so forth.

From there similar functionality will be extracted from game sets and be pushed into the engine, which will allow implementing new features, hardware support and so forth to be done in a less error prone fashion. Eventually the game DLLs will contain only the code that is unique to that game.

While previous parts of the engine were not written based on disassembly, the new release will be source port accurate and any code that does not match the original is being replaced. In fact, the game specific code is being written from scratch from the reverse engineered code. Only once the original code is working is it being refactored and common functionality pulled out to ensure that the results remain "source port accurate."

BTW, the XL Engine forums now have a section for DOS bugs in the games supported, so that the bugs can be ironed out in the respective games' implementation in XL Engine.

This post has been edited by MrFlibble: 18 February 2016 - 08:48 AM

0

User is offline   Mblackwell 

  • Evil Overlord

#23

Er, needing to load assets doesn't it make it not a recreation code-wise.

Seems that he's taken the source and ported what he could into his own engine (the point of XL Engine). To my eyes though he's not updating game tics correctly, which update on two separate timers. It also doesn't appear to have correct visibility fading.

Also for BUILD projects generally the engine was completely separate and unedited by the game developer, and everything for the game (sector effects, ai, etc) was implemented on the game-side code which could be (and usually was) wildly different between titles.
0

User is offline   Forge 

  • Speaker of the Outhouse

#24

View PostMblackwell, on 18 February 2016 - 08:54 AM, said:

Er, needing to load assets doesn't it make it not a recreation code-wise.

if i'm understanding this
decompiling the executable to get the code & filling in the gaps using other build source code is technically 'recreating' it.

i think that we could split hairs all day over how far is "too far" when comparing extremes. Using decompiled code vs. making an engine and trying to recreate a game from scratch that merely 'resembles' the original.
One could say that from their perspective, both extremes are the same thing. Using decompiled code & fill in the gaps = New engine & new (non-build) code.

We can go off on tangents about how far eduke32 has gotten away from the original. The source is still in there somewhere, but it's been eaten & digested a few times.

This post has been edited by Forge: 18 February 2016 - 09:25 AM

1

User is offline   Mblackwell 

  • Evil Overlord

#25

Maybe I'm misunderstanding but from my reading of what's going on it's less like a source port (or decompilation in order to reconstruct the source), and more like using the source to create an asset loader and game-play recreation in Unity.
0

User is offline   Forge 

  • Speaker of the Outhouse

#26

'technically' it is not a 'source port'
if it was, there'd be legal issues

This post has been edited by Forge: 18 February 2016 - 10:02 AM

0

User is offline   Mblackwell 

  • Evil Overlord

#27

But, it's GPL so... not at all?
0

User is offline   Forge 

  • Speaker of the Outhouse

#28

i'm not sure it is GPL. the wiki is pretty weak and vague.
0

User is offline   Mblackwell 

  • Evil Overlord

#29

http://legacy.3dreal...urce_readme.txt

Quote

This is the complete source code for Shadow Warrior version 1.2, buildable as detailed in the next section.

The code is licensed under the terms of the GPL (gnu public license).

1

User is offline   MrFlibble 

#30

View PostMblackwell, on 18 February 2016 - 09:33 AM, said:

Maybe I'm misunderstanding but from my reading of what's going on it's less like a source port (or decompilation in order to reconstruct the source), and more like using the source to create an asset loader and game-play recreation in Unity.

The Daggerfall Tools for Unity is a completely different project altogether. To the best of my knowledge, XL Engine does not use Unity.

Here's a description of the current XL Engine goals in a nutshell:

luciusDXL said:

*DaggerXL will continue, in no way reduced or affected negatively by Interkarma’s excellent work. There are still several reasons for DaggerXL to exist – improved Modding support, including support for existing mods; source-port accurate to the original game, with optional extended features while properly supporting modern systems – including support for software rendering; custom engine designed for high performance even on low-end systems; enhanced features such as extreme view distances (hundreds of km), enhanced texture filtering, enhanced lighting and shadows, etc.

*I have been building tools and other work that will allow me to release source-port accurate support for Dark Forces and Blood at the same time as Daggerfall early in the new year. They too will support software rendering as well as enhanced features. Outlaws has not been forgotten but has been put on hold until a later time. The XL Engine will even allow you to play with your existing save games.

*The XL Engine will be easier to use and setup, automatically setting up the supported games that you have on your system in most cases – easily supporting Steam and GoG versions of the games. It will feature a streamlined interface for adjusting features that the original games did not support (such as adjusting resolution, rendering quality, etc.), rather then implementing game specific interfaces as seen in previous releases of DarkXL or DaggerXL.

*There will be a single entry point – xlengine.exe – with the supported games being implemented as dynamic libraries, allowing for easy addition of new projects in the future. Of course you will be able to make shortcuts to specific games if you want. No launcher, no separate executables.

*Linux and OS X support is still planned but will not be available for the first Beta release.
--------------------------------------------------------------------------------- ---

The first Beta build, coming early in the new year, will feature support for Daggerfall, Dark Forces and Blood. However the initial release will be limited to the software renderer with only limited enhanced features (although basic stuff like higher resolutions will be supported). The XL Engine will still require a GPU with at least OpenGL 1.5 support for compositing and UI (any cards released within the last decade should work, assuming it supports any other games). GPU rendering support will follow shortly, with all the basic features you would expect. However the hardware renderer will require a GPU that supports at least OpenGL 2.0, though higher end GPUs will be required for some extended features such as extreme view distance support (which will not be available in the initial releases). If you do not have a good enough GPU, you will always be able to fallback to the software renderer – assuming you have the aforementioned OpenGL 1.5 or better GPU.
(source)

The initial release (Beta 1) is planned to only support the software renderers of each of the respective games, recreated using reverse-engineering.

View PostMblackwell, on 18 February 2016 - 08:54 AM, said:

Seems that he's taken the source and ported what he could into his own engine (the point of XL Engine). To my eyes though he's not updating game tics correctly, which update on two separate timers. It also doesn't appear to have correct visibility fading.

I think you should inform luciusDXL about these issues that you observe, feedback from people experienced with the Build engine could be valuable for the implementation of Blood.
1

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options