Duke4.net Forums: Duke 3D Voxel Pack - Duke4.net Forums

Jump to content

  • 84 Pages +
  • « First
  • 49
  • 50
  • 51
  • 52
  • 53
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Duke 3D Voxel Pack

User is offline   Borion 

#1501

Couple other small things added lately
Posted Image

And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet:
Posted Image
7

User is offline   NightFright 

  • The Truth is in here

#1502

Fixed Expander ammo with new rotation is on Github. Please test and check if it's OK now.
1

User is offline   LeoD 

  • Duke4.net topic/3513

#1503

View PostBorion, on 19 February 2020 - 05:30 AM, said:

And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet
My vote for the lower one, as ReaperMan implied.
1

User is offline   NightFright 

  • The Truth is in here

#1504

Github update:
- Replaced #1007 neon3 with thick version
- Reverted Expander ammo commit (was rotated by 180° instead of just 90°, better luck next time)
- Deleted some needless maphacks
- Added empty lines in def files where needed
1

User is offline   Borion 

#1505

View PostLeoD, on 19 February 2020 - 06:42 AM, said:

My vote for the lower one, as ReaperMan implied.

Noted! Based on his upvote, I assume Fox is also preferring lower one.
Maybe two more votes and we got a winner :rolleyes:
1

User is offline   Mark 

#1506

lower
3

User is offline   NightFright 

  • The Truth is in here

#1507

I would also go for the double-sided one.
1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1508

No idea.
0

User is offline   Jimmy 

  • Let's go Brandon!

#1509

View PostLeoD, on 17 February 2020 - 11:33 AM, said:

Are you sure that other mappers use that same approach? In 2D mode you see what you get per default. I'd guess that determining the front and where it should point to is more a question of habit. If more mapping 'colleagues' chime in on your behalf, I surely would not object reverting 4444 and deal similarly with other models. Alhough I personally think that the current 'academical' approach provides better consistency and maintainability, and therefore should get the nod. Are there other ongoing projects that are designed to make use of this voxel pack (or even the HRP)? Otherwise, mappers simply don't (have to) deal with sprite orientation and are not affected anyway. I'll gladly provide maphacks for your maps if you don't want go through them in 3D mode again.

Charlie Wiederhold's maps from 1996 had sprite orientations set front-facing. It's almost like he made his maps future proof.

View PostBorion, on 19 February 2020 - 05:30 AM, said:

And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet:

I'd say include both with the lower one as the default. Modders/mappers could find the first one more useful somehow. I'm an options guy. "Why not both?"
3

User is offline   Radar 

  • King of SOVL

#1510

Dual sided one is really fitting since the original art is a view aligned sprite where you can see the napkins at every angle. You can't do that to every voxel so it's cool that this one works out.
4

User is offline   NightFright 

  • The Truth is in here

#1511

Tile #4539 updated on Github. I checked in the single-sided version first, then the double-sided one. This way both are stored in the repo.
1

User is offline   Striker 

  • Auramancer

#1512

Just want to say this is perfect. This is exactly what I meant about the front of the voxel being aligned with the angle of the object.

Posted Image

Thank you. Because of this, it "just worked" with my existing maps.

(No sarcasm in this, btw.)

BTW, is there a chance someone can fix the colors on FOODOBJECT17 (4546), FOODOBJECT18 (4547), FOODOBJECT19 (4548), and JOLLYMEAL (4569)? They were royally palette crushed because they were converted from voxels made for the Shadow Warrior palette.

This post has been edited by Striker: 21 February 2020 - 09:09 AM

1

User is offline   Danukem 

  • Duke Plus Developer

#1513

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.
0

User is offline   Phredreeke 

#1514

Can't you disable voxel rendering for individual sprites?
0

User is offline   Striker 

  • Auramancer

#1515

View PostTrooper Dan, on 21 February 2020 - 11:11 AM, said:

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.

I really think your mod may have something to do with this (or recent EDuke32 builds). I notice that a lot of things that are meant to be one-sided are being rendered. There's supposed to be code that prevents voxels from being rendered if you're behind a one-sided sprite.
0

User is offline   Danukem 

  • Duke Plus Developer

#1516

View PostStriker, on 21 February 2020 - 11:28 AM, said:

I really think your mod may have something to do with this (or recent EDuke32 builds). I notice that a lot of things that are meant to be one-sided are being rendered. There's supposed to be code that prevents voxels from being rendered if you're behind a one-sided sprite.


It's not my mod. I just tested using a vanilla install with nothing added but the voxels and it still happens with the latest Eduke32. I invite you to do the same, just to make sure I'm not crazy or doing something wrong.

EDIT: A quick test case is in E1L1, the switch that opens the armor secret above the concession stand. The one-sided switch is visible if maphacks are not installed.

https://imgur.com/M0q6p1W

You can see I've got voxels installed from the voxels displaying on the counter, and that the one-sided switch is visible.

This post has been edited by Trooper Dan: 21 February 2020 - 11:52 AM

0

User is offline   Striker 

  • Auramancer

#1517

View PostTrooper Dan, on 21 February 2020 - 11:48 AM, said:

It's not my mod. I just tested using a vanilla install with nothing added but the voxels and it still happens with the latest Eduke32. I invite you to do the same, just to make sure I'm not crazy or doing something wrong.

EDIT: A quick test case is in E1L1, the switch that opens the armor secret above the concession stand. The one-sided switch is visible if maphacks are not installed.

https://imgur.com/M0q6p1W

You can see I've got voxels installed from the voxels displaying on the counter, and that the one-sided switch is visible.

Then something is up with the latest EDuke32. One-sided sprites with voxels shouldn't render from behind, maphack or not. Something in the voxel code must have changed over the years, because in old builds this doesn't happen.

This post has been edited by Striker: 21 February 2020 - 11:57 AM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#1518

View PostTrooper Dan, on 21 February 2020 - 11:11 AM, said:

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.
My upcoming Voxels4Maphacks Pack tries to improve on that by moving all voxel switches forward by one unit.

View PostPhredreeke, on 21 February 2020 - 11:27 AM, said:

Can't you disable voxel rendering for individual sprites?
In terms of sprite numbers -yes, by notmd maphacks (you probably knew that). In terms of tile numbers: no, AFAIK.
0

User is offline   Phredreeke 

#1519

Yeah I meant the former. That's how I thought such issues were handled.

(if you wanted to disable by tile number wouldn't you remove the voxel definition itself?)
0

User is offline   Danukem 

  • Duke Plus Developer

#1520

View PostStriker, on 21 February 2020 - 11:55 AM, said:

Then something is up with the latest EDuke32.


Yes. And after some experimentation, it seems connected to the t-sprite array. Setting the t-sprites of the switches to invisible via CON code does not make them invisible. I'm guessing that the t-sprites are set to invisible internally but that is not working any more. However, changing their cstat directly does make them invisible.

Yes, but I don't know what the cause is. I was trying to set tsprcstat to 32768 in ANIMATESPRITES to make them invisible, but actually it needs to be -1. At least now I have a hack that works.

EDIT: No I don't. Because most of the time, setting tsprcstat to -1 makes the game instantly quit without even a log error.

This post has been edited by Trooper Dan: 21 February 2020 - 01:20 PM

0

User is offline   Borion 

#1521

@Striker Foodobject 17, 18, 19 & jolly meal added to to-do list.
1

User is offline   Borion 

#1522

WIP
Posted Image
17

User is offline   NightFright 

  • The Truth is in here

#1523

Github updated with final nuke barrel.

This post has been edited by NightFright: 26 February 2020 - 07:43 AM

2

User is offline   NightFright 

  • The Truth is in here

#1524

Update for slimer egg (558, 675) now also on Github. Hadn't seen those yesterday in my PM.
0

User is offline   Borion 

#1525

View PostNightFright, on 27 February 2020 - 02:41 AM, said:

Update for slimer egg (558, 675) now also on Github. Hadn't seen those yesterday in my PM.

No worries, looks like 558 needs small correction anyway. Will send it during weekend.

Cheers!
0

User is offline   Forge 

  • Speaker of the Outhouse

#1526

dear voxel people,
Your generic pole tile # 977 is broke when flipped and seated to the ceiling.
Sincerely,
Anonymous user that does not want to get backlash for trying to help

DC L4 & E1L4

Attached Image: capt0000.jpg

Attached Image: capt0001.jpg

This post has been edited by Forge: 01 March 2020 - 07:49 AM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#1527

View PostForge, on 01 March 2020 - 07:48 AM, said:

Anonymous user that does not want to get backlash for trying to help
I can't remember backlash for reporting issues without swearwords.
It's not the voxels, it's the renderer. Software is OK, Polymost is not.
Attached Image: E1L4-turrvox-software.jpg Attached Image: E1L4-turrvox-polymost.jpg
[Edit:]HRP/MD3 is OK in both Polys, btw.

This post has been edited by LeoD: 01 March 2020 - 08:36 AM

0

User is offline   NightFright 

  • The Truth is in here

#1528

Yeah, we had reports about this already. In general, always check with classic renderer. What looks OK there is not a voxel bug if it's wrong in other renderers.
0

User is offline   Borion 

#1529

tree1 (908)
Posted Image

I will upload it when tree2 will be done. Makes no sense to replace just one, they are often next to each other.
14

User is offline   NightFright 

  • The Truth is in here

#1530

This seems to be a complex one. Let's hope it doesn't cause any noticable slowdowns when they are used en masse.
0

Share this topic:


  • 84 Pages +
  • « First
  • 49
  • 50
  • 51
  • 52
  • 53
  • Last »
  • 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