[Helixhorned]

Fox, on 22 May 2013 - 09:43 PM, said:

Is it possible to add a cstat flag to control the sprite skewing? By default all sprites are given a perspective view in Polymost and Polymer. However that doesn't work in some cases, in particular enemies practically disappear when looking up or down.

In comparison, Duke 64 seems to have a different display for different sprites. Pictured below, the trees are seen in perspective, while the hydrant or Assault Trooper don't.

That's an interesting suggestion. I added it to the future list.

Hendricks266, on 23 May 2013 - 09:36 AM, said:

I think the issue you're thinking of is billboarding. I know there is a global cvar that controls it, at least for Polymer. However, I could see two mdflags bits: one to prefer the perspective view, one to prefer the screen-facing view, and when you set both, it prefers the opposite of whatever is set by the cvar.

Yes, I think mdflags (spriteext[].flags in C) is the right place to put it, because

• such a flag would be most interesting on a per-tile basis (i.e. set from CON) rather than setting it in the map itself, and
  
• it's pointless for the classic renderer due to its ortho projection in the up/down direction.

I'm less sure about the case with both bits set, though it's neatly symmetric. In the screenshot posted by Fox, the tree trunk must be projected like a wall sprite, while sprites like pickups (and mosters, to a certain degree) are a matter of preference or artistic choice.

[3D Master]

I figured out the problem; the drivers weren't the problem; it's running smoothly down. Such a delight to play Duke3D after forcing myself through forever.

Still wondering if I should pony up the cash for the DLC; on the one hand, this game his horrible, on the other I'll get to see the completion of the god damn cliffhanger ending.

[Jblade]

3D Master, on 24 May 2013 - 08:30 AM, said:

I figured out the problem; the drivers weren't the problem; it's running smoothly down. Such a delight to play Duke3D after forcing myself through forever.

Still wondering if I should pony up the cash for the DLC; on the one hand, this game his horrible, on the other I'll get to see the completion of the god damn cliffhanger ending.

This doesn't mean much, but the DLC is better than the main game (although not by a huge amount I admit)

[Mateos]

3D Master, on 24 May 2013 - 08:30 AM, said:

I figured out the problem; the drivers weren't the problem; it's running smoothly down.

Would be interesting to know what was wrong, in case it happens again to someone else

[Helixhorned]

About modders providing recommendations on which renderers their mods are best played with, I think a good compromise is to make it like map voting in MP. Whenever a map starts in a renderer that is not recommended, a message shows up suggesting the user to switch to a different one. After a timeout of, say, 7 seconds, it disappears if neither Y nor N was pressed.

[Diaz]

Well, my suggestion is not really to make it impossible to use renderers other than intended; just allow modders to make it harder should they choose to do so (so maybe, rather than easily changing renderers in the menu, the user would have to input some console cvar like "r_forcerenderer 0").

It would just make renderer-specific mods cleaner and tidier.

Right now I'm resorting to a full-screen rotatesprite with message that specifies Polymer MUST be used, so at least the mess can't be seen.

I still don't see why anyone would want to play the first screen (really, that shouldn't even be reachable by the user) rather than the second:

Attached thumbnail(s)

• 
• 

[Mateos]

Helixhorned goes for a no-block solution, when the user would see what you posted plus the image he will understand that he really can't play this way, without being forced... Forcing or not, the result is the same.

[Diaz]

No, the result is not the same. There was a cvar in Quake 3 (something like r_allowsoftwareGL) that would allow the game to run in software, although it would be a slideshow and was obviously not supported - do you think it would have been pretty to include that option in the menu? Not at all. But it was still accesible through a cvar for those who really wanted it, though it made no sense.

[3D Master]

Mateos, on 24 May 2013 - 09:19 AM, said:

Would be interesting to know what was wrong, in case it happens again to someone else

Firewall blocked the program demanding a confirmation to allow it to do something just a little too late. Setting it manually solved the problem.

[Mateos]

Thank you for sharing!

[NightFright]

Some oddities with latest r3815:
- "Version Mismatch" for savegames saved with r3813
- On the automap, the levelname is shown together with the 3DR par times, e.g. for E1L1 "00:53 Hollywood Holocaust"
- At least menu tiles 2502/2503 ("Atomic") don't show up any more.

Everything works with r3814 or earlier.

Additionally, I have noticed lately that flickering forcefields turn black while being invisible. See screenshots below. This is with Polymer 32-bit (at least, dunno about the rest) and has been going on for a few builds already as far as I can tell. I have posted my settings here already in case they are needed.

[TerminX]

Yeah, that's my bad. Fixed now! I definitely wasn't paying attention there.

[DavoX]

This might sound really weird and probably a bit dumb but... is it possible to make a mapster32 for mobile platform like android? I know there are millions of shortcuts , keys, etc... but if someone were to do it, would it be possible?

If it were possible in the technical programming side, I could think a few ways to easily navigate and such... considering that smartphones are getting bigger and stronger everyday.

If you disagree I'd like to know why, yeah you

[Paul B]

DavoX, on 27 May 2013 - 09:53 PM, said:

This might sound really weird and probably a bit dumb but... is it possible to make a mapster32 for mobile platform like android? I know there are millions of shortcuts , keys, etc... but if someone were to do it, would it be possible?

If it were possible in the technical programming side, I could think a few ways to easily navigate and such... considering that smartphones are getting bigger and stronger everyday.

If you disagree I'd like to know why, yeah you

It’s not practical nor would the touch screen be accurate enough to work with Mapster. It would be extremely frustrating on a portable device not to mention mapster uses all 104 keys on a keyboard. It would take you 100 years to make one map. It’s hard enough to use Mapster on a laptop with a track pad let alone a mobile touch screen a quarter of the size.

Some things just don’t work well on mobile devices and this would be one of these cases. Even if they did try to develop it for the mobile devices the frame rate would suck because the majority of these mobile devices use ARM based processors. I’m pretty sure the source code requires X86 architecture. They would have to rewrite the entire program just to make it work with ARM processors and they just don't measure up when it comes to performance for complex applications making it not worth the while. As for today's tablets which make use of Intel's X86 processors I still think there would be a huge agrevation factor of trying to map on a small minature device stylus pen or not.


It would be worse than running Eduke with an ATI video card & AMD processor if you can imagine that. I mean common who does that? LOL

[DavoX]

Hmm I understand the technical difficulties, I don't know anything about that but if you say it doesn't work, it doesn't.

About the keys and such, I was thinking that some people use smartphones as pcs connecting keyboards and even mouses to them, I dunno.

Well, doesn't hurt to ask

[Mikko]

Yeah the answer is probably "not anywhere near worth the effort".

[Hendricks266]

The next version of EDuke32 Wii will include a Mapster32 build since I figured out the problems with it. It runs fine if you like 640x480 2D mode and if you have a USB keyboard and mouse. TX was working on an Android port of EDuke32. Once he overcomes the obstacles with that to get the game running, the editor is not too much more work. At the very least, you could search the code for GEKKO to see what needs to be done. On the other hand, you would still effectively need a keyboard. Touchscreen support could be interesting but it might only work best with a stylus.

[Diaz]

Shocking, to say the least

[fgsfds]

Quote

TX was working on an Android port of EDuke32.

Seriously?

[Paul B]

Diaz, on 28 May 2013 - 09:42 AM, said:

Shocking, to say the least

Yea very shocking. The developers must be doing it for the experience and the challenge of making it cross platform. I can't even see anyone even attempting to use it on a wii. That's just strange. I wonder if anyone other than the developers will use the wii version? I just can't see it catering to a very big audience on those platforms. I have a Wii i never use, now this might give me a reason to use my wii and see how well it works. lol

[Hendricks266]

Lol downvotes. Reddiquette, anyone?

My post was more to say that

Paul B, on 27 May 2013 - 10:24 PM, said:

It’s not practical nor would the touch screen be accurate enough to work with Mapster. It would be extremely frustrating on a portable device not to mention mapster uses all 104 keys on a keyboard. It would take you 100 years to make one map. It’s hard enough to use Mapster on a laptop with a track pad let alone a mobile touch screen a quarter of the size.

isn't necessarily correct, and

Paul B, on 27 May 2013 - 10:24 PM, said:

Some things just don’t work well on mobile devices and this would be one of these cases. Even if they did try to develop it for the mobile devices the frame rate would suck because the majority of these mobile devices use ARM based processors. I’m pretty sure the source code requires X86 architecture. They would have to rewrite the entire program just to make it work with ARM processors and they just don't measure up when it comes to performance for complex applications making it not worth the while.

is completely wrong.

Keep in mind that Android means large tablets in addition to smartphones, and smartphone screens are getting both bigger and denser. Combine that with a hardware keyboard as DavoX said and you're approaching mappability. Maybe add some multi-touch gestures to make up for the keyboard.

Yes, the Mapster32 Wii build is essentially for novelty. I wasn't concerned with it myself, but to my surprise people requested it. Go figure.

[Och]

Just downloaded latest HRP 5.2 and latest eduke32 binaries, and it crashes immediately after level load. Everything works fine with early January 2013 binaries of eduke32, but once I try february or later, the game crashes.

[DavoX]

Post your log.

[Och]

Here you go, logs for working version and log for broken version. Both are exactly the same, the only thing that is different - in the broken version eduke32.exe is 5.28.13 and in the working its 1.5.13

Attached File(s)

•  working.log (12.55K)
  Number of downloads: 555
•  broken.log (13.31K)
  Number of downloads: 571

[Och]

If I disable polymer, it doesn't crash with the newest eduke32

[Hendricks266]

Do you see a file named eduke32_or_mapster32.crashlog? If so, could you post it here? (You may need to rename it to crash.log.)

[Och]

Well, just updated my catalyst drivers from 13.1 to 13.4 and it now works, no more crashes!

Still surprised to see FPS dip into low 20ies at time, on a pretty high end PC. Are there any performance improvements planned to the polymer renderer?

[Master Fibbles]

Yes, there are always performance improvements planned. But, in the mean time, you could try this fix.

Spoiler

OK, obvious troll...but, there is a history of ATI cards not working well with the game.

[Paul B]

[quote name='Hendricks266' timestamp='1369772557' post='160049']

Sorry Hendricks266, I don’t agree with you. Of course the mobile computing has dramatically improved but I believe mobile computing serves a small and limited purpose. For instance, my smart phone I use to check my e-mail but you will never see me button mash to create an e-mail and send it from my phone its a waste of time. I do not believe desktop applications such as map editors should migrate to portable miniature devices just to keep up to a trend. I also believe this mobile trend is a fad and I’ll be glad when the focus comes back to PC. In my opinion it’s a waste of freakin’ resources and time to fulfill what purpose? So that 2 or 3 people who can't sit in front of their computer can lay on their bed and map edit with a stylus? I am not on board with this idea as this software will never be a good fit for mobile computing and it’s a waste of time pursuing. Unless you plan on turning Eduke into a flash player based game and redoing the entire mapster interface into a drag and drop system.

Just a thought, maybe you could incorporate Mapster to work with Siri voice recognition. Then we could pump out Duke Nukem maps with dictation on mobile devices. Now that would be kick ass!

"Siri build sector by X, Y & Z coordinates! use floor tile 773 and wall tile 878". That could actually make things faster instead of using touch, keyboard and mouse functions to some degree.

[Hendricks266]

Mr.Flibble, on 28 May 2013 - 02:31 PM, said:

there is a history of ATI cards not working well with the game.

Whenever this is explained, it should always be clarified that it's ATI/AMD's fault for making bad drivers, not ours for being deficient as a program. We already have workarounds in place for ATI's problems but we can't work around everything.