Duke4.net Forums: revision 6893 Mapster locking up - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

revision 6893 Mapster locking up

User is online   Mark 

#1

Yesterday I installed the latest, 6893, to test out 3 bug fixes from the devs. It fixed all 3. But since then Mapster has locked up 3 times and I had to use task manager to close it out.

EDIT: I see 4 more revisions came out since I downloaded yesterday. Did any of them address this issue?

This post has been edited by Mark.: 23 May 2018 - 05:44 AM

0

User is online   Mark 

#2

I think I opened my mouth too soon. So far it seems to be working fine after I deleted my textures cache files and let them rebuild. Many times over the years that has been a fix for graphical glitches in Eduke32. This is the first time I can remember having to do this for Mapster too.

On a side note, I seem to remember reading recently that Eduke32 now uses a higher default cachesize setting and will ignore any lower setting found in cfg files. It doesn't look like that is the case for Mapster. I still see a lower setting in my log file. Is that change only for Eduke32?
0

User is online   Danukem 

  • Duke Plus Developer

#3

View PostMark., on 23 May 2018 - 10:52 AM, said:

I think I opened my mouth too soon. So far it seems to be working fine after I deleted my textures cache files and let them rebuild.


Yeah, if you use a newer EDuke32 or Mapster32, drop it into an older project folder that has existing cache files and try to run, then you will get a message that the cache has "locked up". This has been true for at least the last few months of revisions.
0

User is online   Mark 

#4

Son of a bitch. It locked up again. This time I was in 2D mode. I saved the map I was working on. A few seconds later I wanted to load another map. I pressed L to load, scrolled to the next map, hit enter and mapster locked up. Thats what happened last time. And the time before that it locked up when switching from one mode to the other. I don't remember which way. So this is the 4th time its locked up for me.

Edit: I was able to duplicate the freeze 2 more times now when switching to a new map.

Edit again: I went back to my previous version of 6482 from Oct 2017 and I can't duplicate the lockup. So I'm fairly certain it has something to do with later revisions.

This post has been edited by Mark.: 23 May 2018 - 02:48 PM

0

User is online   Danukem 

  • Duke Plus Developer

#5

log files?

is the lockup cache related?
0

User is online   Mark 

#6

No log errors. It ends in the middle of loading textures. It shows as expected the textures being cached in the Textures file. I've not seen the "cache locked up" message probably because I skipped from Oct 2017 straight to the latest yesterday.

I had Task Manager run in the backround. For CPU usage it has 2 windows. Assuming one for each core in my ancient core-duo system. One was low usage the other was at near 100 percent during the freeze. Total in the bar graph was shown as 50 percent. Plenty of remaining memory.

This post has been edited by Mark.: 23 May 2018 - 04:17 PM

0

User is online   Mark 

#7

Here is the blow by blow description of the reproducible lockup error. FYI this is in my HHR project.

Version 6893 installed. Deleted textures and textures cache files for a clean start.
1. Ran Mapster and loaded up map 1. Wandered through the entire map to get all the textures into the new cache files.
2. Closed down Mapster. I have 170MB textures file.
3. Ran Mapster and loaded up map 1 again. As expected it ran smoother with the new cache files.
4. Closed down Mapster.

Then I repeated steps 1-4 but using map 2. I have 339MB textures file now after both maps have run.

Ran Mapster. Loaded map 1 and roamed around for a few seconds in 3D mode. Switched to 2D mode so I could load up map 2. Selected map 2 and hit enter. Mapster freezes. Log shows no errors.
0

User is online   Mark 

#8

ARRRGGG!!!

Once again I did the task I hate. I narrowed down the lockup. 6775 is good. 6777 = lockup issue
2

User is offline   pogokeen 

  • EDuke32 Developer

#9

Thanks for the detailed report -- sorry that you're encountering this issue!
I'm working to fix this. I'll post an update here as soon as I have a fix ready.
0

User is online   Mark 

#10

ok. thanks
0

User is offline   pogokeen 

  • EDuke32 Developer

#11

I've pushed a fix for this (r6906). Sorry again for the trouble!
3

User is online   Mark 

#12

I'll give it a try shortly.

No lockups. Woo hoo!

This post has been edited by Mark.: 26 May 2018 - 02:38 PM

0

User is offline   pogokeen 

  • EDuke32 Developer

#13

Glad to hear it! :(
1

User is offline   Kyanos 

#14

------------------------------------------------------------------------

Quote

r6905 | pogokeen | 2018-05-23 08:04:56 -0700 (Wed, 23 May 2018) | 1 line

engine.cpp: fix issue with voxmodel_t voxels not having their scale set properly due to defs being processed before PolymostProcessVoxels()
------------------------------------------------------------------------
r6904 | pogokeen | 2018-05-23 08:04:52 -0700 (Wed, 23 May 2018) | 3 lines

engine.cpp: fix classicDrawVoxel() positioning bugs by:
+avoid adding the pivot's z offset again after it was already added in classicDrawSprite()
+offset the voxel object by half of the voxel object's z size
------------------------------------------------------------------------
See http://svn.eduke32.c...repname=eduke32 for more details.


So I decided to check the recent changelogs after reading this thread, these two fixes have been a long time coming. Thank you.
0

User is offline   pogokeen 

  • EDuke32 Developer

#15

No problem! :P I appreciate it!

My focus right now is on fixes and improvements to rendering, so there'll be more like that to come :(
1

User is offline   TerminX 

  • el fundador

  #16

View PostDrek, on 26 May 2018 - 02:53 PM, said:

------------------------------------------------------------------------


So I decided to check the recent changelogs after reading this thread, these two fixes have been a long time coming. Thank you.

Yeah, they needed to be addressed for a certain game in production currently. :( I had no idea that shit was even broken until we created test assets and discovered it was completely screwed up...
1

User is offline   Kyanos 

#17

View PostTerminX, on 26 May 2018 - 05:52 PM, said:

Yeah, they needed to be addressed for a certain game in production currently. :( I had no idea that shit was even broken until we created test assets and discovered it was completely screwed up...

It all started back when a major change was introduced for android compatibility, like 2014?? I think all floats got changed to doubles or something like that. I know a few things were said about voxel issues since then, but there's been a lot going on with EDuke32 in the meantime and I'm just glad it's finally been sorted out.

This post has been edited by Drek: 27 May 2018 - 11:02 AM

0

User is offline   TerminX 

  • el fundador

  #18

It was the other way around, all doubles got changed to floats except for a few cases where doubles were still required for the extra precision. It boosted speed a ton, even on PC! :(
1

User is offline   Kyanos 

#19

I like that vox2poly doesn't run for software mode anymore, thought I would report that some voxels aren't drawing in Polymost, to check load Reapermans pack, rooftop of HH, invisble pistol ammo.
0

User is offline   Kyanos 

#20

I checked and it was the latest revision which caused the error of disappearing voxels in Polymost. 6905 is ok.

This will be my last post about this in this thread, I'm probably going to make a Voxels General thread to keep tabs on the current state of them as EDuke32 continues to improve. Another bug I still see is the shadows moving about, they will jump into view when the player is still looking at the sprites sector but not able to see the sprite itself... the shadow moves with the player angle. I can go into more detail or provide pics, video, testcase...

Finish on a high note. I've just loaded the entire HRP worth of voxels into the software renderer, 140MB. It wants more, it was a 3 second load time, looks amazing, all the enemies, bosses, duke... everything voxelized.
0

User is offline   pogokeen 

  • EDuke32 Developer

#21

Thanks for reporting those issues. I'll take a look & work to get those fixed up! :(
0

Share this topic:


Page 1 of 1
  • 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