![Image](http://i2.kym-cdn.com/photos/images/original/000/585/038/03a.jpg)
ReDuke: Duke Nukem 1 for Windows
@Lass ![LOL :lol](./images/smilies/emotikeen-lol.gif)
I have only played MW2 and the campaign had me *facepalm*-ing all through it.
Especially the part with a US operative undercover with the Russian 'terrorist' who he's supposed to assassinate.
while they mow down civilians in an airport he has so many chances of killing him.
And due to stupidity in programming (and the fact that he's one of the main enemies later), after you get shot while trying to get in their getaway van if you managed to throw a grenade in and have it explode while you are bleeding out: the mission fails! (yes I know that's not supposed to happen, but still...)
http://www.youtube.com/watch?v=1VuVRE6BOJc
![LOL :lol](./images/smilies/emotikeen-lol.gif)
I have only played MW2 and the campaign had me *facepalm*-ing all through it.
Especially the part with a US operative undercover with the Russian 'terrorist' who he's supposed to assassinate.
while they mow down civilians in an airport he has so many chances of killing him.
And due to stupidity in programming (and the fact that he's one of the main enemies later), after you get shot while trying to get in their getaway van if you managed to throw a grenade in and have it explode while you are bleeding out: the mission fails! (yes I know that's not supposed to happen, but still...)
http://www.youtube.com/watch?v=1VuVRE6BOJc
mortimermcmirestinks wrote: Now I wish MoffD wasn't allergic to me.
Levellass wrote:You're an evil man.
![Image](http://i.imgur.com/E35CiVd.gif)
I just re-read this and it made me laugh. The game runs at 16 frames per second! Always has, always will. But yeah, super-smooth._mr_m_ wrote:EDIT: This runs super-smooth.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
The latest (and most likely last) version of ReDuke (Beta 4) is now hosted on the Duke Nukem 3D: High Resolution Pack website. Scroll down to the bottom of the page.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
-
- Vortininja
- Posts: 48
- Joined: Sat Sep 14, 2013 9:52
ReDuke
ReDuke looks pretty cool i must say, however you should include a full wide render of, in game, and not only clamped to 5:3 screenK1n9_Duk3 wrote: ↑Sat Nov 05, 2016 22:37 The latest (and most likely last) version of ReDuke (Beta 4) is now hosted on the Duke Nukem 3D: High Resolution Pack website. Scroll down to the bottom of the page.
One of the problems for example with duke nukem 2, is that the visual is too narrow, so enemies creeps up to you too suddenly
I think a true widescreen mode can give the overall game play a new addition
Re: ReDuke: Duke Nukem 1 for Windows
First of all, Duke Nukem II is not supported by ReDuke. I began working on "ReDuke II", which would have been ReDuke for Duke Nukem II, but that project didn't get very far, since many events in Duke Nukem II are based on "random" chance. Recreating that without disassembling or decompiling the original DOS game would be (almost) impossible.
I did think about adding a true widescreen option to ReDuke when I was working on it, but there are just too many issues that such a feature would cause, so I decided not to waste my time implementing it.
The goal of ReDuke was (and still is) to recreate the original gameplay, so that demos recorded in the original version would show the same gameplay in ReDuke. Most of the enemies and other interactive objects in Duke Nukem behave differently depending on whether they are visible or not, so changing the viewport size to full widescreen would break the demo compatibility. For example, there can be only up to 3 enemy shots active at the same time, so if you increase the viewport size, more enemies might be visible at the same time and some of them can shoot while others can't (because there are already 3 enemy shots visible on the screen). With the relativly small viewport in the original game, you would rarely notice this limitation, but with a full widescreen viewport, it will be noticed sooner or later.
And a bigger viewport might even result in situations where you see parts of the level that were never meant to be seen. Plus, the backdrops are designed for this rather small viewport area, so increasing the viewport size would lead to even more visual problems.
So yes, a true widescreen mode will give the overall game play a new addition: The game will be broken.
Don't get me wrong. It would be possible to fix all these issues, but the result would be more of a Duke mod/fangame/remake instead of being a faithful recreation of the original game. I don't like it when ports or recreations vary too much from the original gameplay mechanics (like the sprinting in Commander Genius or the jumping in ZDoom and WinROTT).
I did think about adding a true widescreen option to ReDuke when I was working on it, but there are just too many issues that such a feature would cause, so I decided not to waste my time implementing it.
The goal of ReDuke was (and still is) to recreate the original gameplay, so that demos recorded in the original version would show the same gameplay in ReDuke. Most of the enemies and other interactive objects in Duke Nukem behave differently depending on whether they are visible or not, so changing the viewport size to full widescreen would break the demo compatibility. For example, there can be only up to 3 enemy shots active at the same time, so if you increase the viewport size, more enemies might be visible at the same time and some of them can shoot while others can't (because there are already 3 enemy shots visible on the screen). With the relativly small viewport in the original game, you would rarely notice this limitation, but with a full widescreen viewport, it will be noticed sooner or later.
And a bigger viewport might even result in situations where you see parts of the level that were never meant to be seen. Plus, the backdrops are designed for this rather small viewport area, so increasing the viewport size would lead to even more visual problems.
So yes, a true widescreen mode will give the overall game play a new addition: The game will be broken.
Don't get me wrong. It would be possible to fix all these issues, but the result would be more of a Duke mod/fangame/remake instead of being a faithful recreation of the original game. I don't like it when ports or recreations vary too much from the original gameplay mechanics (like the sprinting in Commander Genius or the jumping in ZDoom and WinROTT).
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
-
- Vortininja
- Posts: 48
- Joined: Sat Sep 14, 2013 9:52
Re: ReDuke: Duke Nukem 1 for Windows
I used duke nukem2 as a reference to my concern of the narrow viewport.K1n9_Duk3 wrote: ↑Sun Feb 26, 2017 22:01 First of all, Duke Nukem II is not supported by ReDuke.
And a bigger viewport might even result in situations where you see parts of the level that were never meant to be seen. Plus, the backdrops are designed for this rather small viewport area, so increasing the viewport size would lead to even more visual problems.
So yes, a true widescreen mode will give the overall game play a new addition: The game will be broken.
Don't get me wrong. It would be possible to fix all these issues, but the result would be more of a Duke mod/fangame/remake instead of being a faithful recreation of the original game. I don't like it when ports or recreations vary too much from the original gameplay mechanics (like the sprinting in Commander Genius or the jumping in ZDoom and WinROTT).
However duke nukem 1 doesn't suffer that much from it.
Duke 2 does, because how fast some sprites moves horizontal in such a narrow viewport witch would give you very little response time
I can see your dillema you would enconter, but i still wonder if the viewport was a little wider, would the issue be the same.?
And the far most enemies would act like ghost sprites, like they only do walk animation, and your rail from your gun cant reach them, but you could
prepare your move before enconter
Re: ReDuke: Duke Nukem 1 for Windows
Yes. Just take a look at the levels of Duke Nukem and Duke Nukem II. Most of the levels in Duke Nukem 1 are "incomplete". The developers didn't bother finishing the parts of the levels that the player wouldn't be able to see in the game. By increasing the viewport size, these might become visible.Batteryman wrote: ↑Mon Feb 27, 2017 20:04 [if the viewport was a little wider, would the issue be the same.?
In Duke Nukem II, the first level consists of an indoor and an outdoor area. As you can see from the level image (see link above), both areas are actually stored in the same level. You just can't notice that because the relatively small viewport won't allow you to look up or down far enough to see it. If you increase the viewport too much, players would be able to see it.
One issue that both games have in common is the fact that the backdrops were designed for the viewport size. In Duke Nukem, each backdrop is exactly as big as the viewport, so if you increase the viewport size, parts of the screen will be missing the backdrop. You can't just repeat the existing backdrop to fill the empty space because the backdrop images weren't designed for that.
The backdrops in Duke Nukem II are full 320x200 pixel images, but not all backdrops use the full height of the image, so you can't increase the viewport size in that game either without showing parts of the backdrop that weren't meant to be seen by the player.
You should realize by now that you can't just change the viewport size in the code and get away with it. You would have to create new graphics and might even have to edit the levels so that your new version doesn't look broken. That would be way beyond the scope of ReDuke. You could do something like that in a complete remake, but not for a simple drop-in replacemanet of the game's executable.
Well, that's not how the actor code in ReDuke works. The actor's animation can only change if the actor is updated, which means the actor would also be allowed to move. Unlike the original DOS game, ReDuke would theoretically be able to draw the actors without allowing them to move, but I wouldn't see this as a "feature". If I were to see enemies "stuck" at the edge of the screen (or worse, floating above the player's head) I would think the game is broken. Therefore, I won't be doing that.Batteryman wrote: ↑Mon Feb 27, 2017 20:04 And the far most enemies would act like ghost sprites, like they only do walk animation, and your rail from your gun cant reach them, but you could prepare your move before enconter
![No :no](./images/smilies/emotikeen-no.gif)
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
Re: ReDuke: Duke Nukem 1 for Windows
Indeed, indeed. Be it laziness or craft, these games are very well constructed to take advantage of their resolution. Changing this would be cool for an expansion, but not an adaption like this.
Also, just a question for someone who knows the code; in episode 1, level 5 at the top of the level is a jumping robot. He can be lured right when the player is one 'level' below him and made to jump through the reactor. When the robot jumps up to the top-rightmost section of the level (with the bomb and balloon box) he vanishes offscreen... and out of the level. Going to that spot later reveals nothing and I can not find the bot anywhere else. What happened to it and why?
Also, just a question for someone who knows the code; in episode 1, level 5 at the top of the level is a jumping robot. He can be lured right when the player is one 'level' below him and made to jump through the reactor. When the robot jumps up to the top-rightmost section of the level (with the bomb and balloon box) he vanishes offscreen... and out of the level. Going to that spot later reveals nothing and I can not find the bot anywhere else. What happened to it and why?
What you really need, not what you think you ought to want.
-
- Vortininja
- Posts: 48
- Joined: Sat Sep 14, 2013 9:52
Re: ReDuke: Duke Nukem 1 for Windows
Interesting thing with those atlas'es , didn't know they exist.
I really like your explanation, very informative, i't might came in handy for someone other, if they wonder in the future about the same topic
I really like your explanation, very informative, i't might came in handy for someone other, if they wonder in the future about the same topic
Re: ReDuke: Duke Nukem 1 for Windows
The jumping robot (I usually call it jumpbot) jumps through the ceiling and out of sight. This happens because the collision dectection usually only checks if the tile directly above the actor is blocking and if it's not blocking, the actor will move up. The thing is that the very first part of the jumpbot's jump actually moves it up by two tiles. As you can see from the maps I linked to above, the area at the top of the level is a corridor that is three tiles high. Since the jumpbot itself is two tiles high, it checks the tile above it and finds it to be non-blocking. It then moves up two tiles, which means the "head" of the jumpbot will be inside the outermost row of the map. In the next frame, it would again check if the tile above it (at y coordinate -1) is blocking. Since this is outside the actual map, the result of that check depends on memory allocation and other things. I don't remember the specifics off the top of my head and I don't have access to my ReDuke stuff right now. But what happens is basically that the jumpbot ignores the tile at the very top of the level and therefore may or may not be able to jump through it. I think I actually implemented the collision detection in ReDuke in a way that it doesn't try to access data that's not inside the map boundaries, but I can't remember right now what ReDuke does in that case. I think all tiles "outside" the map are blocking in ReDuke, but I'm not sure about that.Levellass wrote: ↑Tue Mar 07, 2017 9:51Also, just a question for someone who knows the code; in episode 1, level 5 at the top of the level is a jumping robot. He can be lured right when the player is one 'level' below him and made to jump through the reactor. When the robot jumps up to the top-rightmost section of the level (with the bomb and balloon box) he vanishes offscreen... and out of the level. Going to that spot later reveals nothing and I can not find the bot anywhere else. What happened to it and why?
The Jumpbot will stay "alive" after jumping out of the level and it will be updated each frame, but you never get to see or hear any of that. And there's no way for it to get back into the actual level, because I don't think it can ever move by 2 tiles in one frame when falling.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
Re: ReDuke: Duke Nukem 1 for Windows
I'm liking that explanation; that's a very... odd way for such a sprite to move. In fact I've noticed a few shortcuts and poorly coded things in Duke over the years; it's certainly no Keen Galaxy. I'm wondering now about making custom maps that let you trick enemies off the level tops and bottoms...
What you really need, not what you think you ought to want.
Re: ReDuke: Duke Nukem 1 for Windows
Examples?
I could say the same about Keen Galaxy (or, more precisely, about BioMenace), as far as the actor vs. actor collision detection is concerned. As you should know, the id engine uses a generalized object structure that stores pointers to various Think, React and Contact functions with the Contact function defining what should happen if that object touches another object. This leads to tons of useless collision checks, because the game has to check every object against every other object. So if you have n active objects, the game needs to check up to n² possible collisions. (Actually it's slightly less than n², but still a pretty large number).
In Duke Nukem, each actor type handles it's own contact detection, so most actors only need to check if they hit the player or a player shot. And since every actor type is stored in its own array, these checks can be done at peak efficiency. I don't know what the maximum number of objects in the Keen games is (I know it's 125 in BioMenace). Duke Nukem 1 on the other hand usually allows up to 100 objects of each type, so the game can actually handle several thousand active objects per level. Since there can only be up to 4 player shots active at the same time, the game only needs to perform up to 5*n checks where n is the number of active actors/enemies.
In short:
BioMenace -> 125² = 15625 checks
Duke1 -> 3000*5 = 15000 checks
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
Re: ReDuke: Duke Nukem 1 for Windows
Keen Galaxy can be... inefficient. But remarkably robust. Even when modding it's difficult to get the game to break, there are error checks for all sorts of problems.
This leads to things like Keen's shooting code, which is used by all of his shooting frames, but then requires a check for each possible frame for different shot offsets. Then there's Keen's death code that checks for an intended but never used 'already dead' frame.
Collision checks aren't that bad; sprite-sprite are only run when two objects are touching so n active objects only run n^2 checks if, improbably all are touching at once. And some sprites will only run their collision once per touch. (This is an example of either genius or laziness since it means that, for example, Keen can appear in front of a deadly enemy and not die because its 'kill Keen' collision isn't run.) The game also handles active and inactive objects carefully basically only sprites onscreen are active and need to run checks.
The collision system also allows for a whole lot more variety. In Duke basically no enemies interact; it's you against them against your shots. That's fine but it divides interactions into hurt player\hurt enemy. In Keen you can have enemies that are not dangerous when doing certain things and even enemies that can affect each other. Even Keen 1 had an enemy that could stun others while Duke's enemies allow their own shots to harmlessly pass by.
Notably sprite-tile checks that prevent sprites getting stuck in solid tiles. In Duke you can trap enemies in elevators, or get dynamite to explode through them. In Keen Galaxy this is strictly avoided via a special system to detect when things are where they shouldn't be and to eject them by the shortest route possible.
Duke... Duke is efficient but limited. A prime example is the 'only 4 player shots active' thing. In Keen Galaxy the player can produce up to 70 shots which remain active offscreen. They can be fired in any of 4 directions and there's leftover code that suggests 8 directions were considered. This has the effect that Duke can shoot quicker if he's closer to an enemy, ridiculously fast when it comes to, say, Dr. Proton and knocking him out in a few seconds. In Keen shot rate is always the same (And it's possible to patch in Duke-like firepower.) If the game's sprite array is formed new sprites simply won't spawn (Excluding when levels load.) Duke can be great performance-wise but you get issues, like the flame canon things producing flames offscreen that can hurt you when you fall past them onscreen again.
What especially gets me is the mirror floors. For the longest time I wondered why they'd show black or white until I figured out how it was they made a reflection of what was above them and how. Once you notice that it's hard to ignore the workaround.
The bouncing mines too are a neat trick, they don't actually bounce off of solid surfaces, they follow a predetermined path. This is great performance-wise but they lack the flexibility of their Galaxy equivalents (Spindred and even Mad Mushroom which can be made into obstacles via their interaction with solid tiles and bridges.) Then there's simple things like the fixed level size and the backgrounds being a single viewport-sized image. Great for cutting down on computing but... limited.
This leads to things like Keen's shooting code, which is used by all of his shooting frames, but then requires a check for each possible frame for different shot offsets. Then there's Keen's death code that checks for an intended but never used 'already dead' frame.
Collision checks aren't that bad; sprite-sprite are only run when two objects are touching so n active objects only run n^2 checks if, improbably all are touching at once. And some sprites will only run their collision once per touch. (This is an example of either genius or laziness since it means that, for example, Keen can appear in front of a deadly enemy and not die because its 'kill Keen' collision isn't run.) The game also handles active and inactive objects carefully basically only sprites onscreen are active and need to run checks.
The collision system also allows for a whole lot more variety. In Duke basically no enemies interact; it's you against them against your shots. That's fine but it divides interactions into hurt player\hurt enemy. In Keen you can have enemies that are not dangerous when doing certain things and even enemies that can affect each other. Even Keen 1 had an enemy that could stun others while Duke's enemies allow their own shots to harmlessly pass by.
Notably sprite-tile checks that prevent sprites getting stuck in solid tiles. In Duke you can trap enemies in elevators, or get dynamite to explode through them. In Keen Galaxy this is strictly avoided via a special system to detect when things are where they shouldn't be and to eject them by the shortest route possible.
Duke... Duke is efficient but limited. A prime example is the 'only 4 player shots active' thing. In Keen Galaxy the player can produce up to 70 shots which remain active offscreen. They can be fired in any of 4 directions and there's leftover code that suggests 8 directions were considered. This has the effect that Duke can shoot quicker if he's closer to an enemy, ridiculously fast when it comes to, say, Dr. Proton and knocking him out in a few seconds. In Keen shot rate is always the same (And it's possible to patch in Duke-like firepower.) If the game's sprite array is formed new sprites simply won't spawn (Excluding when levels load.) Duke can be great performance-wise but you get issues, like the flame canon things producing flames offscreen that can hurt you when you fall past them onscreen again.
What especially gets me is the mirror floors. For the longest time I wondered why they'd show black or white until I figured out how it was they made a reflection of what was above them and how. Once you notice that it's hard to ignore the workaround.
The bouncing mines too are a neat trick, they don't actually bounce off of solid surfaces, they follow a predetermined path. This is great performance-wise but they lack the flexibility of their Galaxy equivalents (Spindred and even Mad Mushroom which can be made into obstacles via their interaction with solid tiles and bridges.) Then there's simple things like the fixed level size and the backgrounds being a single viewport-sized image. Great for cutting down on computing but... limited.
What you really need, not what you think you ought to want.
Re: ReDuke: Duke Nukem 1 for Windows
I think we can both agree that all of these games/implementations had their upsides and downsides. They all had to take shortcuts here and there so they could run on the slow systems of their time. Id software wanted to show off the smooth scrolling technology John Carmack had created, so that's what they did with the Keen games. What Duke Nukem did was to prove that you can have an entertaining game without using cutting edge technology. The game didn't have pixel-perfect scrolling and didn't run at 60 or 70 frames per second, but it was still fun.
John Romero had an article on his old website talking about the birth of id Software. He wrote that he showed Carmack's smooth scrolling tech demo "Dangerous Dave in Copyright Infingement" to everyone who would come by his office. He also wrote that some of them weren't overly excited and did not see the potential that he saw. Duke Nukem showed that those pepole weren't ignorant or stupid.
On the other hand, Duke Nukem would not have been the game we know today if Apogee didn't get in contact with the guys that would later become id Software. The code for the PC Speaker sound effects and the joystick input and calibration is the same code that was used in earlier Softdisk/id Software games. That is why the credits screen in Duke Nukem says "Special thanks to: id Software".
John Romero had an article on his old website talking about the birth of id Software. He wrote that he showed Carmack's smooth scrolling tech demo "Dangerous Dave in Copyright Infingement" to everyone who would come by his office. He also wrote that some of them weren't overly excited and did not see the potential that he saw. Duke Nukem showed that those pepole weren't ignorant or stupid.
On the other hand, Duke Nukem would not have been the game we know today if Apogee didn't get in contact with the guys that would later become id Software. The code for the PC Speaker sound effects and the joystick input and calibration is the same code that was used in earlier Softdisk/id Software games. That is why the credits screen in Duke Nukem says "Special thanks to: id Software".
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net