[Lunick]

Hah, I saw Dave like your post on FB and thought the sprites were very nice

[xMobilemux]

Video Preview:

[Fox]

This is a concept of how the Doom engine could be replicated in Eduke32. I am using E1M1: Hangar because it's the standard showcase map. Not sure of what I will do with this yet.

Hud view



Misc screenshots

[Fox]

Skybox view, 8bit and 32bit modes



Partial invisibility, 8bit and 32bit modes



Invulnerability, 8bit and 32bit modes



Light amplification visor similar to pre-release Doom BETA, 8bit and 32bit modes

[Micky C]

There's a lot of nice stuff happening in this thread over the last few days, I like it all

[zykov eddy]

Fox, looks awesome! Btw, how's your Wolf 3D mod?

[xMobilemux]

I've managed to finally get my DNF Cycloid in DN3D Looks ok I guess

[zykov eddy]

Wow, this is impressive. Are you planning to add some new sounds and coding?

[xMobilemux]

zykov eddy, on 03 June 2012 - 12:07 AM, said:

Wow, this is impressive. Are you planning to add some new sounds and coding?

I'm only a beginner but once I learn, I'm gonna make a complete overhaul with: new levels, weapons, monsters, sounds etc

EDIT: I also threw in this to see what it would look like lol I wont rush it next time cause it looks kinda cool IMO

[NUKEMDAVE]

Wesker500, on 03 June 2012 - 12:24 AM, said:

I'm only a beginner but once I learn, I'm gonna make a complete overhaul with: new levels, weapons, monsters, sounds etc

I know how to map and add sounds.

[Mark]

Darn it. Ever since I got this skeleton placed in the game I can't concentrate on the rest of the game. I keep getting sidetracked doing this stuff.

Attached thumbnail(s)

• 

[darkcaleb]

That's impressive Wesker500, may i ask how your're doing that and is it possible to converting the original models?

Hehehehe funny picture Marked, How's progress?

[Fox]

A while ago I was working on a more efficient (at least for me) rain code. I believe at this point there are plenty of rain codes, but I made one that satisfy myself. This may be a little complicated to explain.

Most of the rain codes essentially spawn rain particles on an area above the player. Whenever the player is moving, there will be a noticeable different number of particles towards the position he is moving to.

In the case of the code I created, I made so that whenever the players moves, the particles out of range will spawn on the other side of the rain area, for both horizontal and vertical directions. It took a lot of work to make this work properly, and was quite a logic challange, but I am satisfied with the result.

Also, in order to make the rain more concentrated with the same amount of particles, all the sprites remain in the player field of view, so there won't be particles hidden behind the player.

As a result, as you walk you will have the illusion of particles popping out of nowhere in front of you. This effect is aggravate by the fact the number of particles is concentrated around the player (and smoothly fades away). But this effect is expected (not to say it was sort of intended).

[Danukem]

That's nice! Although it would take a movie to actually show what you are talking about. It must have been difficult to make it so that the rain looks uniform when the player turns around suddenly.

[Fox]

Here is a video:

[Mblackwell]

Not bad. I can tell it follows the player, but it doesn't really detract very much. You should randomly spawn splash particles along the ground in areas the rain falls.

[thatguy]

Mblackwell, on 04 June 2012 - 07:09 AM, said:

Not bad. I can tell it follows the player, but it doesn't really detract very much. You should randomly spawn splash particles along the ground in areas the rain falls.

It follows the player? But you can still see the rain outside when you're inside.

[TerminX]

Lately I've been working on porting EDuke32 to Android. There's no major progress yet, though the code is already at a point where it compiles, links and builds into an .apk package. Someone who looks to have considerable experience with porting SDL based stuff to Android has tentatively agreed to help out so I'm hoping the time frame won't turn into a complete disaster like the multiplayer code (though to be fair, an Android port requires so much less work than the multiplayer code does so it's not really even a valid comparison).

[Paul B]

TerminX, on 04 June 2012 - 10:27 AM, said:

Lately I've been working on porting EDuke32 to Android. There's no major progress yet, though the code is already at a point where it compiles, links and builds into an .apk package. Someone who looks to have considerable experience with porting SDL based stuff to Android has tentatively agreed to help out so I'm hoping the time frame won't turn into a complete disaster like the multiplayer code (though to be fair, an Android port requires so much less work than the multiplayer code does so it's not really even a valid comparison).

TerminX don't be so hard on yourself. Whenever something changes new challenges emerge. Obviously the net code was functional at some point and something changed to make it not work. Is there anything the community can do to contribute to the net code completion? You talk about the net code being a disaster but you never explain why it was a disaster or what the challenges you are facing? Perhaps, talking about it publically can lead to some good ideas from the community or at least assist in the process of bringing back the functionality.

[TerminX]

No, the networking code was never really functional. It's a WIP rewrite of multiplayer in a client/server fashion that required entirely abandoning the original networking code (the old code from the DOS days that frequently went out of sync) and starting over from scratch. There is not much to talk about... I started the rewrite shortly before I got engaged, and then getting married and having a kid took my free time away. The multiplayer is unfinished because I do not usually have long enough blocks of free time to do the kind of work that needs to be done with it.

[Fox]

Mblackwell, on 04 June 2012 - 07:09 AM, said:

Not bad. I can tell it follows the player, but it doesn't really detract very much.

It doesn't exactly "follow" the player.

The visual effect is the very same as if there was thousands of particles everywhere in the map, but they are only visible when the player is closer to them. And in order to make the number of particles more concentrated around the player, and the range which it becames visible is randomized for each particle.

Of course on reality there is a limited amount of particles that are constantly jumping of location to give that illusion. In the video I used a limit of 2048 particles (while around 20% are always omitted due to a technicality).

[Danukem]

It looks pretty good, but the rain drops fall too quickly.

[Sebastian]

I think the rain/snow looks perfect already. I don't think you should add any splash or anything on the ground, never did like the way that could sometimes bug out when you're building alot of sprites.
Best weather/particles effect I've seen yet.

[OpenMaw]

TerminX, on 04 June 2012 - 11:06 AM, said:

No, the networking code was never really functional. It's a WIP rewrite of multiplayer in a client/server fashion that required entirely abandoning the original networking code (the old code from the DOS days that frequently went out of sync) and starting over from scratch. There is not much to talk about... I started the rewrite shortly before I got engaged, and then getting married and having a kid took my free time away. The multiplayer is unfinished because I do not usually have long enough blocks of free time to do the kind of work that needs to be done with it.

Somebody really needs to get on this. Honestly, the community would HUGELY benefit from having a functional multiplayer experience for Duke3D. Even the hack around that Vinny and I use isn't perfect. (Using YANG and an older version of the game).

Life has to take first position obviously...

[wayskobfssae]

Fox, on 03 June 2012 - 05:03 PM, said:

A while ago I was working on a more efficient (at least for me) rain code. I believe at this point there are plenty of rain codes, but I made one that satisfy myself. This may be a little complicated to explain.

Most of the rain codes essentially spawn rain particles on an area above the player. Whenever the player is moving, there will be a noticeable different number of particles towards the position he is moving to.

In the case of the code I created, I made so that whenever the players moves, the particles out of range will spawn on the other side of the rain area, for both horizontal and vertical directions. It took a lot of work to make this work properly, and was quite a logic challange, but I am satisfied with the result.

That's a great idea! I only did it for a starfield in a sidescroller before, so I understand the concept. So out of curiosity, for the boundary around the player that instructs the particles to teleport, did you choose a square, or did you dare try it with a circle?

[Fox]

It functions as a square, since that's how I make the offset with x-y coordinates. But some partciles are hidden in order to make it looks like a circle. It would have been mind blowing to make that with a real circle (I tried).

[Forge]

Trooper Dan, on 15 June 2009 - 01:41 AM, said:

The average length of time between someone contributing to a Duke project and the contribution seeing the light of day is somewhere between six months and six hundred years....

ah, the wisdom of the ancients...

they should change the title of this thread to "best screen shot of stuff nobody will ever see"

[Mark]

I resemble that remark.

[Mark]

I'm guilty as charged.

[Micky C]

No, because you're going to release your stuff