[icecoldduke]

M210, on 06 July 2017 - 12:32 PM, said:

I'm not said that something is better....I said twice, that is same.

You can't even say that. You can't take shit out, and do comparisons. As far as your GTA thing, I can't speak for that. I don't know anything about that project of yours. I can only say eduke32 is heavily CPU bound, and the problem is going to be worse in your engine because its on Java.

[m210®]

icecoldduke, on 06 July 2017 - 12:34 PM, said:

You can't take shit out, and do comparisons.

I'm not going to start doing the Duke3D port to prove to the blind person the same performance. I just showed my early works in which you can trace the fps trend.
In any case, you can continue to praise "your lovely language" and blindly believe that Java is 10 times worse. With the same success, you can consider "your lovely language" a fully shit in comparison with assembler. That's all, folks I'm gonna sleep

[jablon1000]

Gentlemens!

What the point of this disscussion? About old PC, Java or what? Its pointless. Maybe old PC cant handle eduke or something, maybe bloodgdx performance is quite weak, mayby java is quite slow language BUT this theard is about news of bloodgdx the ONLY ONE working BLOOD port of ALL TIME!

[Jim]

Doesn't Nightfreights portable java already took care of most of the spyware/viruses concerns?

[icecoldduke]

M210, on 06 July 2017 - 12:44 PM, said:

I just showed my early works in which you can trace the fps trend.

It worries me a bit that you don't understand that Java is a lot slower then C++. It further worries me that you answered my technical question, with nonsense . You can't answer my performance questions with, "my past projects aren't slow, so this one won't be either".

M210, on 06 July 2017 - 12:44 PM, said:

With the same success, you can consider "your lovely language" a fully shit in comparison with assembler.

Modern C/C++ compilers can beat most hand written assembly.

[Dzierzan]

Most of people here just want Blood being playable without need of Dosbox and without any fancy stuff. I am not a fan of Polymer either, it kinda takes away DN3D original feel. So what Java is slower? Is it the end of world? Or maybe it was M210's plan to troll you icecoldduke . Nah, just kidding. The point is I have to agree this conversation is useless and it's already off-topic.

[Emmanuelexe]

icecoldduke, have you tried the port? Because it's played really like the original, even better, smoother, better render and more options, so, 99% of the players don't care if it's made with java or not, downloading it is not a big deal, also yes, it's our only BLOOD port, Monolith will never do anything with Jace Hall and a real Blood port so better to take it.

And M210 is allowed to do what he wants but im bored to see so much negativity about our only fan port who is made for free by a guy (yeah, there is donation but it's up to us to do that if we want).

Do your own port then? Did he stole something from you to say "you should have used our "own engine"? like a program or other?
Because i don't know why he shouldn't be allowed to do what he wants.

Anyway, if the port was bad, we could say, it's bad and java is bad but it's not the case. If people don't want download java, it's up to them, but with all the things we check on internet, roms, emulations, movies and stuff, java is not the bigger risk for a pc, right?

And not like if it was a big deal, seeing where we are, in a small community who survive hard, this kind of salt against bloodgdx does not help.

[icecoldduke]

Manhs, on 06 July 2017 - 05:53 PM, said:

...

This is what technical discussions look like. His gameplay is solid, but hes going to hit a ceiling soon because of his tech choices.

To answer your question, yes, I have played his port. Here are my 10 minute findings:

• The bi-linear filter looks like shit on the UI.
  
• Why do you lock the framerate to 60fps?
  
• I was getting below 60 fps on 4k resolutions (i7, 32gb DDR4 ram and NVIDIA Geforce 1080).
  
• Also on startup, my mouse runs like shit until the game displays the monolith logos

[Hendricks266]

icecoldduke, on 06 July 2017 - 01:09 PM, said:

It worries me a bit that you don't understand that Java is a lot slower then C++. It further worries me that you answered my technical question, with nonsense . You can't answer my performance questions with, "my past projects aren't slow, so this one won't be either".


Modern C/C++ compilers can beat most hand written assembly.

ice, I'm observing this thread and I identify strongly with the quote "what we have here is failure to communicate". The fans just want to play Blood, and if it looks like Blood, smells like Blood, and tastes like Blood, then it's Blood to them and they don't care. You and M210 are not speaking the same language, both literally and figuratively. I giggle to see mention of "your program is CPU bound" when clearly BUILD lives and breathes CPU based algorithms, from the classic renderer, pure software, to Polymost, more of the same but with some extra bubblegum and paper clips attaching it to the very latest in 3D rendering circa 2004. Your highly specialized industry talk doesn't have any traction outside of those circles of employment.

jablon1000, on 06 July 2017 - 12:52 PM, said:

Gentlemens!

What the point of this disscussion? About old PC, Java or what? Its pointless. Maybe old PC cant handle eduke or something, maybe bloodgdx performance is quite weak, mayby java is quite slow language BUT this theard is about news of bloodgdx the ONLY ONE working BLOOD port of ALL TIME!

BloodGDX is a combination of an old version of EDuke32's engine ported to Java with a Blood game codebase of the stolen alpha source code from February 1996, augmented with bite-size reverse engineering of Blood 1.0 first, and 1.21 later. It's always going to be buggy.

All I'm going to say is, Always Bet on EDuke32.

[Forge]

*waiting on EDduke64*

[icecoldduke]

Hendricks266, on 06 July 2017 - 07:39 PM, said:

...

I get the hint .

[m210®]

icecoldduke, on 06 July 2017 - 06:32 PM, said:

• The bi-linear filter looks like shit on the UI.
  
• Why do you lock the framerate to 60fps?
  
• I was getting below 60 fps on 4k resolutions (i7, 32gb DDR4 ram and NVIDIA Geforce 1080).
  
• Also on startup, my mouse runs like shit until the game displays the monolith logos

[*] because it's NOT bi-linear filter
Before throwing clever terms, find out what it mean
[*] I'm not lock framerate....you did it...and you also can disable it.
[*] You will have almost same framerate in old-builds of eduke32
[*] Because mouse driver for lwjgl was written on c++....you see that? I said on c++...it's a old driver when I will change on never version at future. Anyway I haven't problems as you with mouse.....maybe because my Celeron has better performance then your i7?

And btw, I know, that Java may slower on ~20% but not at all, so you are wasting your time for 2 months
And look at this benchmark
https://bytonic.de/h...benchmarks.html
I using lwjgl, therefore you need see on last column

Hendricks266, on 06 July 2017 - 07:39 PM, said:

iwith a Blood game codebase of the stolen alpha source code from February 1996

It does not matter, because all the methods have been rewritten to actual

[m210®]

About alpha codes....this is code from alpha version:

void GetZRange( SPRITE *pSprite, long *ceilZ, long *ceilHit, long *floorZ, long *floorHit,
	int clipdist, char cliptype )
{
	dassert(pSprite != NULL);

	short oldcstat = pSprite->cstat;
	pSprite->cstat &= ~kSpriteBlocking & ~kSpriteHitscan;
	getzrange(pSprite->x, pSprite->y, pSprite->z, pSprite->sectnum,
		ceilZ, ceilHit, floorZ, floorHit, clipdist, cliptype);
	pSprite->cstat = oldcstat;
}

There is a code from v1.21

public static void GetZRange( SPRITE pSprite, int clipdist, int cliptype )
	{
		if(pSprite == null) dassert("pSprite != null");
	
		short oldcstat = pSprite.cstat;
		pSprite.cstat &= ~kSpriteBlocking & ~kSpriteHitscan;

		getzrange(pSprite.x, pSprite.y, pSprite.z, pSprite.sectnum, clipdist, cliptype);
		
		gz_ceilZ = zr_ceilz; gz_ceilHit = zr_ceilhit;
		gz_floorZ = zr_florz; gz_floorHit = zr_florhit;
		
		if ( (gz_floorHit & kHitTypeMask) == kHitSector ) {
		    int sectnum = gz_floorHit & kHitIndexMask;
		    if ( (cliptype & 0x2000) == 0 && (sector[sectnum].floorstat & 1) != 0 )
		    	gz_floorZ = 0x7FFFFFFF;
	
		    int nXSector = sector[sectnum].extra;
		    if ( nXSector > 0 )
		    	gz_floorZ += xsector[nXSector].Depth << 10;

		    int nUpper = gUpperLink[sectnum];
		    if ( nUpper >= 0 ) {
		    	int nLower = sprite[nUpper].owner;
		    	if(nLower >= 0) {
			    	getzrange(pSprite.x + sprite[nLower].x - sprite[nUpper].x, pSprite.y + sprite[nLower].y - sprite[nUpper].y, pSprite.z + sprite[nLower].z - sprite[nUpper].z, sprite[nLower].sectnum, clipdist, cliptype);
			    	gz_floorZ = zr_florz; gz_floorHit = zr_florhit;
			    	gz_floorZ -= (sprite[nLower].z - sprite[nUpper].z);
		    	}
		    }
		}
		
		if ( (gz_ceilHit & kHitTypeMask) == kHitSector ) {
			int sectnum = gz_ceilHit & kHitIndexMask;
			if ( (cliptype & 0x1000) == 0 && (sector[sectnum].ceilingstat & 1) != 0 )
				gz_ceilZ = 0x80000000;
		    int nLower = gLowerLink[sectnum];
		    if ( nLower >= 0 ) {
		    	int nUpper = sprite[nLower].owner;
		    	if(nUpper >= 0) {
			    	getzrange(pSprite.x + sprite[nUpper].x - sprite[nLower].x, pSprite.y + sprite[nUpper].y - sprite[nLower].y, pSprite.z + sprite[nUpper].z - sprite[nLower].z, sprite[nUpper].sectnum, clipdist, cliptype);
			    	gz_ceilZ = zr_ceilz; gz_ceilHit = zr_ceilhit;
			    	gz_ceilZ -= (sprite[nUpper].z - sprite[nLower].z);
		    	}
		    }
		}
		pSprite.cstat = oldcstat;
	}

Attached File(s)

•  ??????????.png (14.8K)
  Number of downloads: 28

[fgsfds]

GDX vs eduke run on a potato. I think icd is really overestimating the impact Java has on a performance in this case.

Attached File(s)

•  IMG_20170707_163305.jpg (146.8K)
  Number of downloads: 86
•  IMG_20170707_163303.jpg (128.72K)
  Number of downloads: 76

[icecoldduke]

Sorry for derailing this thread. Might be worth creating another thread for me and M210 to argue tech, but it would be worth taking my technical advise.

[Devon]

i dont understand coding but what i do know is that this BloodGDX runs smoother than any other build engine game port i have ever tried.
i got 800-2000fps uncapped in BloodGDX v0.769 in 4k with game companion in the background to get rid of tearing.


Win10 x64
x2 850evo raid0
Msi gtx1070
32gb 2133mhz ddr3
I7-4790k 4.7ghz


I dont know why the build engine ports runs with worse on my system compared to this blood port....So many milisec hickups and stutter here and there.

Anyway i love all of you great coders who makes these ports like Eduke32 and proasms swp.

Also the polymer renderer is an amazing feat wich alot of us including me thought was just an april fools joke when that first screen was shown of duke in the bathroom on the first level.


Best regards! =)



edit:
This is most noticible in shadow warrior, in the first level just strafe and look how it IS NOT smooth. Then run BloodGDX and strafe and IT IS smooth.
Well atleast on my rig...
At first i thought it was a sync issue but this apperently isnt a vsync on/off issue or framecap on/off thing either.
Doesnt matter wth i do and this ihas been present on the last three computers i built spanning almost 10 years.

Something is done differently in bloodgdx and i want to know why it runs butter smooth when not even the mighty eduke32 stable or most recent build does not in comparison.
Dont get me wrong though eduke32 runs good enough but still what is going on ?

[Tekedon]

I must agree with this port feeling very smooth, don't know what it is but it feels like butter. I have the same FPS or more in eduke32 but still this feels more smooth somehow.

[J432]

Manhs, on 06 July 2017 - 05:53 PM, said:

icecoldduke, ... Do your own port then?

He tried. This is his attempt and maybe a reason he criticizes M210 so vehemently :
www.youtube.com/watch?v=7DcnyFviito

[icecoldduke]

J432, on 07 July 2017 - 05:01 AM, said:

He tried. This is his port and maybe a reason he criticizes M210 so vehemently :
www.youtube.com/watch?v=7DcnyFviito

My thing was a disaster . Can't expect more out of a 8th grade though.

[J432]

icecoldduke, on 07 July 2017 - 05:04 AM, said:

My thing was a disaster . Can't expect more out of a 8th grade though.

Yes, but you can try again now when you are more experienced and make something better in accord with your suggestions to M210 about an ideal Blood port.

[Devon]

icecoldduke, on 07 July 2017 - 05:04 AM, said:

My thing was a disaster . Can't expect more out of a 8th grade though.

Lend your experience to this =)

[J432]

Hendricks266, on 06 July 2017 - 07:39 PM, said:

The fans just want to play Blood, and if it looks like Blood, smells like Blood, and tastes like Blood, then it's Blood to them and they don't care.

Exactly.

Hendricks266, on 06 July 2017 - 07:39 PM, said:

All I'm going to say is, Always Bet on EDuke32.

Is it another cryptic promise about things that may be coming? Great, but I prefer something I can play before I die as I am not Caleb that can live again.

[gordon81]

J432, on 07 July 2017 - 05:51 AM, said:

Exactly.



Is it another cryptic promise about things that may be coming? Great, but I prefer something I can play before I die as I am not Caleb that can live again.

Great words.

I think the same. It's stupid to focus on the Eduke engine when fans what we want is something that makes us enjoy the original game as it came out.

Mods, improvements, textures, and any other crap is irrelevant as long as the original game base remains different from the original concept.

Personally Java I do not like, but it has brought back the Blood as and as I knew it in its day, so I think we should respect the author, and if necessary, help him improve Java support that is the tool with the Which is working.

On my wish list there are only two things left, panoramic resolution support and cd music.

Again I thank the author for all the effort he is making to bring back this great game and that we can play it once and for all.

[m210®]

eDuke32 also have interpolation...but maybe it doesn't enable for sprites?
I remember I made request to add interplation for floorz/ceillingz but no one listened to me For making interpolation of floorz it's need to include sectoreffector with lotag 31/32 and after that, sector was interpolated.

Btw, first KenBuild game also have interpolation, and I I experimented with it. You can make sprites updating for a one per second, but you will still see the smooth movement of sprites

[Mblackwell]

http://wiki.eduke32.com/wiki/Htflags

It's not enabled by default because it changes the appearance of the original game (which only updates every few tics). Just OR 8192 on to a sprite's htflags.

[Hendricks266]

Mblackwell, on 07 July 2017 - 07:14 PM, said:

http://wiki.eduke32.com/wiki/Htflags

It's not enabled by default because it changes the appearance of the original game (which only updates every few tics). Just OR 8192 on to a sprite's htflags.

That's a Duke 3D game-side feature. The htflags member is part of actor_t, in source/duke3d/src/actors.h.

[fgsfds]

icecoldduke, on 06 July 2017 - 06:32 PM, said:

• The bi-linear filter looks like shit on the UI.

Implying it doesn't look like shit in the game.
I don't know why it's even an option in many ports. Why would anyone use any kind of filtering in a sprite-based game? All of them look like garbage compared to the nearest when applied to a low-res textures.

[Sledgehammer]

What's worse is that sprites looks blurry as fuck if you have big screen especially, this is where it is very noticeable. I always feel like I have terrible eyesight after looking at this filter.

[icecoldduke]

fgsfds, on 08 July 2017 - 12:36 AM, said:

Implying it doesn't look like shit in the game.
I don't know why it's even an option in many ports. Why would anyone use any kind of filtering in a sprite-based game? All of them look like garbage compared to the nearest when applied to a low-res textures.

I agree. Making things blurry, doesn't make things look better .

[Jim]

fgsfds, on 08 July 2017 - 12:36 AM, said:

Implying it doesn't look like shit in the game.
I don't know why it's even an option in many ports. Why would anyone use any kind of filtering in a sprite-based game? All of them look like garbage compared to the nearest when applied to a low-res textures.

Everything looking like tiny little squares ain't that great either.