Duke4.net Forums: What do you think about BloodGDX ? - Duke4.net Forums

icecoldduke, on 20 July 2017 - 07:33 PM, said:

+1

Mblackwell, on 20 July 2017 - 08:06 PM, said:

Don't forget coffee.

I make mine half decaf so I can drink twice as much

So lets start the technical discussion.

BloodGDX is done in Java. One issue that we haven't talked about yet is how and if M210 will take new eduke32 engine changes over to BloodGDX. Did M210 only port over Polymost or did he port over Polymer as well? Will he take the engine stability fixes that have gone in since he branched off from duke4's svn?

BloodGDX uses leaked alpha code. M210 is that the reason why you don't open source your work? What's your view on code mods? You mentioned before releasing some "game code sdk", why wouldn't you just open source your work? You went out of your way to obfuscate your binary. Can you elaborate a bit on why you did that?

BloodGDX doesn't include the map editor. Do you have plans to port over the map editor as well? M210, in your mind, what is the priority of user made content?

icecoldduke, on 21 July 2017 - 06:23 AM, said:

+1

icecoldduke, on 21 July 2017 - 06:23 AM, said:

I can't find the quote right now but he has already answered "no".

Hendricks266, on 21 July 2017 - 08:50 AM, said:

No he said he might, after he is done with everything else he is planning.

Tekedon, on 21 July 2017 - 08:52 AM, said:

I think he was joking.

M210, on 14 July 2017 - 11:43 AM, said:

icecoldduke, on 14 July 2017 - 12:50 PM, said:

M210, on 14 July 2017 - 08:00 PM, said:

Mblackwell, on 20 July 2017 - 05:02 PM, said:

What the bloody hell? Please do enlighten me on how to percieve 4k fps with human sensory system. I must know!

That and obviously you haven't read my rather long and boring post on where I assume the bottleneck of BloodGDX is going to be.

Also, silly commentary aside, picking random number ranges does not make your claim any more scientific or valid than mine. To fix that, how about taking BloodGDX for a ride on your rig, try to squeeze some numbers from it and report it here? Somehow I doubt I could get 2k from Polymost on my 12 years old ThinkPad with Intel GMA... Do you agree?

kimec, on 21 July 2017 - 10:51 AM, said:

What was your assumption?

High Treason, on 20 July 2017 - 06:52 PM, said:

Sure thing, I believe the technique of wrapping words into brackets originates from 4chan. It should represent an echo or some cetral sound progressing in a form of sound waves through a void and that way underlining the meaning of the word.

icecoldduke, on 21 July 2017 - 10:59 AM, said:

My assumption was, that the bottleneck is going to be JNI (Java's foreign function interface). All calls to OpenGL from BloodGDX need to pass through it. In native binary, you don't pay that cost obviously, so no mather how cleverely JVM optimizes/JIT compiles the Java part into native code of the target platform, BloodGDX will always pay a (constant?) cost for JNI access while EDuke will not.

However, whether that constitutes anything significant and percievable by the player during gameplay is another story.

Also interesting is how I've got -2 karma points for trying to be both technical and objective without whiteknighting. Wasn't a heated debate encouraged previously?

Really makes you wonder.

kimec, on 21 July 2017 - 11:24 AM, said:

The overhead of OpenGL calls from java doesn't help the situation but I doubt thats whats causing the performance issues. I've done a lot of profiling on Polymost and the issue is the gaps between draw calls where the engine tries to figure out what to draw next.

icecoldduke, on 21 July 2017 - 12:13 PM, said:

Look I am not familiar with EDuke, BUILD engine or the Polymost renderer internals. I've registered on this forum mainly to track BloodGDX progress and to be able to comment.
I've mentioned JNI because that is a known cost for sure, however, since M210 has not released the source of BloodGDX and on top of that even started to obfuscate the compiled byte code, making judgements about the possible reasons out of thin air is pure speculation. Yes, Java does not have structs and pointer arithmetic and you have to make up for that whenever porting C code.

I think we need to realize, that M210 did not only "port Blood to Java". He ported also BUILD and Polymost along the way. I think it is safe to say, that BUILD has now a "pure" Java port which could make headlines on Reddit by it self even without Blood. And anything or nothing might have gone wrong there. Ditto Polymost.

I really like where bloodgdx is now. Doesn't need to go even much further for me.

Also no performance issues whatsoever.
Yeah it's java, but for what it needs to do, it seems to work well enough.

I replay blood every year and this has been the smoothest replay ever.

M210 did say that he hopes to port mapedit but it probably wont be until the far future. I think we should continue to request this as mapedit will be essential for growing the Blood community (which is largely lopsided to other build games). Tekedon and myself make up for almost half of the active mappers for Blood. Which is a shame considering there is a great website with tutorials and tools.

http://www.baitd.bloodgame.ru/bme.htm

What holds back mapping for blood with Mapster32? Is there a complex tag system like SW?

Drek, on 21 July 2017 - 03:55 PM, said:

Way more complex then shadow warrior.

Drek, on 21 July 2017 - 03:55 PM, said:

I recall hearing you could manipulate all kinds of physics in the editor. I.e those useless vel(ocities) tags in the Duke map format actually mean thing related to velocity

icecoldduke, on 21 July 2017 - 04:30 PM, said:

Ywah, I found this stuff...

Quote

Those are sector types. I've explained the X-System several times over the years and I'm not doing it in depth again.

Nonetheless, interesting points are;
Individual walls and sprites can be marked to move, not move, or move in reverse. Mark with K.
You can set movement waveforms - such as elevators starting slow and getting faster over time. I think F5/F6 opens the Sprite/Wall/Sector edit dialog.
The tags were replaced with Rx/Tx channels, 100 are reserved for the system (Hit F10 to get the first free channel) so you can do really creative stuff, complex machines are easier to make, not needing clocks+bellows as I use in Duke3D, though you can make one with a single sector, without sprites, and have precise timing.
You can set On/Off states in 3D mode using F3/F4, you can toggle between the set states with F2.
You can set lights, wind and panning for any sector individually via an in-depth "FX" menu.
Transparent ROR is possible with only two sprites, one per floor/ceiling, these use "Data" Channels instead of Tx/Rx IDs. Multiple-sector ROR is possible if you're resourceful in exploiting the game's no-draw stuff.
A broad Gib/Projectile spawning possibility.
Activate send channel at On/Off/Specific conditions met.
According to the Alpha notes, the system was inspired by Dark Forces early on.
Some enemies can be woken up using their Rx ID.
Countless potential for exploits to make cool effects.
Respawns can be used multiple times.

To name a few. Whilst I think SW uses unused bits for the boolean tags and such, I've never been sure if Blood made modifications engine-side or game-side. I suspect game-side.
Worth noting that you CAN map geometry for Blood in Mapster, but the converters lose the art tiles, setting everything to Tile 0 Shade 0, possibly due to Blood's encrypted MAP format and its weird ART handling. Blood can also load animated Smacker textures, this is how the cutscenes play and that smooth fire effect works.

There once was a weather system, handled by Blood.ini, I think some of the tiles for it exist in earlier builds. Seems it simply slapped animated rain/snow over the screen.

icecoldduke, on 21 July 2017 - 06:23 AM, said:

Nice post +1

For the map editor, people could use the dosbox BUILD but it could be better to have a real new editor who is easier to use, not a priority for me but what i hope is a good multiplayer with dedicated server who can be stable because dosbox had a lot of desynch with my internet (or it's usual?) and it can lag a lot >< Can it be better with java?

Manhs, on 21 July 2017 - 11:39 PM, said:

Implementation language is irrelevant. Proper netcode rewrite is going to be major undertaking for all BUILD engine derivatives, native or Java. It took several rewrites for Quake to get it right. However there is one shortcut BloodGDX could take and that is split screen.

kimec, on 22 July 2017 - 12:04 AM, said:

Splitscreen co-op would be awsome!

Zaxx, on 20 July 2017 - 04:40 PM, said:

He actually has been speaking about it much longer. I am curious if we will first see something from Hendricks or Lucius.

Hendricks266, on 30 November 2014 - 07:47 PM, said:

J432, on 22 July 2017 - 06:19 AM, said:

Maybe one day, who knows, I'm just not that optimistic because so far every other attempt at porting the game failed so I get the idea more and more that in order to succeed you really just have to stop giving a damn about the potential legal issues. I don't think Lucius or Kaiser lied honestly, I think they just hit a problem they couldn't solve maybe because of the legal issues and if the aim is to protect the copyright of a 20 years old game then I'm sure all the other attempts will fail too. Hell, for all we know it's possible that Kaiser is sitting on a functional source port right now but he's not releasing it because of the legality of all.

Anyway it's funny to read this so called technical discussion because basically the whole thing is pointless: M210 clearly can't speak English properly so he'll get only the information Google Translate let's him... and when it comes to specific vocabularies Google Translate is worth nothing. On top of that I don't even see anything substantial being discussed here (apart from the legal issues), it's basically just Hendricks and icecoldduke being a bit jealous because they did not port the game first. This kind of competitiveness is weird to me because honestly EDuke32 is a big enough project to maintain properly alone and it already lags behind stuff like the ZDoom based source ports for Doom. I'd like to see BloodGDX evolve but I'd love to see EDuke32 getting new features too like xBRZ texture upscaling, better frame pacing and better vsync support, generally a better way to manage screen tearing than just having two huge ass horizontal tear lines on the screen, support for Nvidia Fast Sync, maybe Vulkan implementation, better support for World Tour etc. etc. Sure, the Duke 3D modding community is nothing like what is going on for Doom but a great, up to date source port to Duke 3D would still be wonderful.

And now I'll stop since I'm clearly steering away from the thread.

Zaxx, on 23 July 2017 - 05:55 AM, said:

No one is jealous of M210's work. If you sense any form of hostility from me, its only because his work is closed source. Mod development is the only way to keep these old games alive, if no one is making mods for a game, the game slowly fades away into oblivion. To set the record straight, I'm glad M210 got to the finish line before anyone else. I'm not happy that is work is closed source. I'm personally holding out hope that there is another port in progress, that will be open source, that will match M210's level of quality, that will bring more modders to the game.

I am waiting on answers to the rest of my questions though .

icecoldduke, on 24 July 2017 - 06:40 AM, said:

Well, I think everyone has seen the screenshots Kaiser posted from BloodEX so there is definitely another reverse-engineered port out there even if it's unfinished:

But the thing is the last time Kaiser said anything about this project he was on the opinion that even if he were to release it he'd do it secretly, maybe just by posting a sneaky little torrent somewhere because he wants to avoid legal issues. In my mind that's understandable but honestly as someone who knows a thing or two about how stuff like this is handled on the practical side (disclaimer: I don't deal with software yet, I have to educate myself on that subject a lot more) I see no chance of that happening because the companies involved are just not interested in the IP. It's evident at this point that WB is not selling the Blood IP because a company like that loves to protect its assets by holding on to them but they won't spend a dime on protecting it apart from that. Atari is in even worse shoes: they can publish the first game but seems like that's the furthest they can go with it so again they won't spend a cent on protecting it.

I can give you a great example on why this matters: remember Armikrog, the "spiritual successor" to Neverhood? Armikrog shares so many similarities with Neverhood that it could be considered illegal when it comes to copyright law: the game simply uses all the distinctive characteristics of Neverhood to the point where EA, the company that has the rights to Neverhood could take that to court and they would win. Why could Armikrog happen then? Because EA does not care, they don't want to do anything with the Neverhood IP apart from holding on to it because that's the only perspective where it's important for them to some extent: company value. You can be certain that there was communication between the devs of Armikrog and EA where EA just said "we don't care, you can do it as long as it's not called Neverhood."

I think that's why BloodGDX is important: if people who are afraid of legal problems see now that it's out and that absolutely nothing is happening when it comes to the legal stuff then that could act as a catalyst. We could see more ports surface because there is an example that shows that there's nothing to be afraid of.

And I get why you're a bit hostile towards the project not being open source, free software is part of the culture when it comes to developers like you: you prefer open source, you usually try to show good will by publishing your work under the GNU GPL etc. but somewhere you just have to understand that if someone takes advantage of the grey area that could benefit guys like you in the long run. Honestly I have no problem with the project being closed source as of now because I think that shows the good will here: we don't know why M210's is keeping the source to himself but it kinda presents a statement to the IP holders that "hey, I'm not putting it out there, it's not my decision." That could matter.

Also when I meant that you're jealous I did not mean it in a harmful or agressive manner but more like a sense of healthy competition (still getting those downvotes though but I don't see a problem with that, it usually happens when I'm provocative in order to make a point ). What I find weird is the technical discussion because clearly there is a language barrier here (and potentially an unwillingness) so I doubt it will be fruitful but well, at least you're trying.

Anyway I'm not a programmer, I'm just a gamer but even I see that open source would be better because in my mind EDuke32 should be "retired" in a sense and upgraded into something like the Doom source ports: one software that could play Duke 3D, Blood and Shadow Warrior at least, basically "EBuild32" and guess that's not happening without everyone being open source and working together. That would revitalize the modding scene.

Sorry for the wall of text btw.

icecoldduke, on 24 July 2017 - 06:40 AM, said:

All of my life I trying to learn programming and tried to ask people some question, but people are reluctant to answer my questions and sometimes criticize...for example, people can't help me and answer how to working GL20 renderers and I needed to find this information myself. I wasted a lot of time for learn that, and still haven't a fully answer. So, I'm understood, why people don't say their algorithms, because it's their secret, they're "know how", because they also spent their time and they don't want anyone to get this information so easily. So, why I need to show my "know how"? I want that people themselves have passed this unbearable path like me and I don't will see my project by other people, whos called my projects his own.

But, maybe I just want more people to remember me .... and when that happens, I'll open my source code...maybe
And there is a only way to prove that Java is not as bad as they think about it

And I just don't need competitors at this stage, I just want to do it from the beginning to the end