Which of these features should I turn into a PR? #1656
Replies: 10 comments 6 replies
-
|
In order ones I would like to have would be 1 High Framerate, 8 Hotbar, 9 Hold left mouse button to attack and 10 Hold right mouse to attack, 6 Safety jog, 11 Display health and mana as numbers. For the hotbar maybe the belt could go next to the inventory panel for 640x480 and if a panel is opened on the other side it would go behind it or disappear. |
Beta Was this translation helpful? Give feedback.
-
|
I think you need the hardware UI rendering for the hotbar. So my suggestion is 1.hardware rendering UI, 2.hotbar, and 3.complete hardware rendering and 4 light mapping! All this work could serve as a solid base and someone might pick up your work and develop it further if you loose interest in it. I'd love to see all completed though! Cheers! And keep up the good work! |
Beta Was this translation helpful? Give feedback.
-
Oh yeah, I forgot to mention the hotbar needs the hardware UI renderer. Though, if we find a way to scale down icons (either through code or by adding new assets) then it would work in software too. |
Beta Was this translation helpful? Give feedback.
-
|
I think you should work on the hardware rendering, lightmapping and opaque walls first. The high framerate looks really nice, but I wonder how it would look with increased game speed. Some of the other stuff (hotbar, paperdoll) looks like mod territory. |
Beta Was this translation helpful? Give feedback.
-
With my implementation of high framerate, I made it possible to adjust game speed separately. So, for instance, it would be possible to run it at 60fps but everything runs twice as fast as it should. And for the heck of it, I added a separate speed setting for monsters. So you could play with monsters being extra fast or slow compared to overall game speed. |
Beta Was this translation helpful? Give feedback.
-
|
999999999999999999999999999 when can you have it ready? My suggested priority list: 4, 5, 7, 14 might not be fully relevant but the code cleanup might be interesting. Also some comments for the other options. 1: Would be amazing, but I think we would like to go a different route more in the style of what has been done with animation fps. Or at least we need to get time demos running first so that we can automate verification of gameplay. 2: Lots of people are asking for independently scaled UI since they like the game at high resolution but that leaves the UI hard to use. 3: Also great, but we probably need to make it a hybrid to get the rendering more accurate or go full-blown OpenGL. But a starting point would be to decouple the render so that others could be supported, which you seem to already have done here, so if you start with that we can go from there. 4: This looks like it would make 3 worth it even if they are not exactly matching in the black levels. Maybe that is solvable? The downside as you mention is that it would be a lot of work. I defiantly recommend breaking it down into smaller changes that can be done iteratively. 6: I think this would be appreciated as a QoL, despite me feeling strange about it :) 7: Pretty stealthy, if there are some abstractions or cleanups related to it those parts would be interesting. 8: A bit of a game-changer, but we do defiantly want to make things flexible enough to support alternative UIs like that. Again, introduce it gradually would be the way to go. 10: Not a bad idea, again, we should definitely make the code support it, but maybe that comes with configurable key mapping anyway, so don't know if that changes how relevant this is? 11: I hate it but lots of people love it, should be added as a QoL as soon as anyone has time to do a PR, this could be you! 12: I would defiantly want to try it out and see how it feels :) 13: Nice QoL, fire away. 15: Do the hardware rendered UI first :D 16: Definitely the nicest solution to the problem, but maybe I have just learned to live with it to the point where it's not high on the priority list. Personally though I would rather enable this then alt highlighting. |
Beta Was this translation helpful? Give feedback.
-
I could work on this next. But the feature needs quite a bit more work since I've changed how the code updates the selection of entities.
I should note that my implementation currently doesn't allow for UI to be resized separately. UI rendering happens in the same places as software rendering using similar values. |
Beta Was this translation helpful? Give feedback.
-
As someone who is new to this project, it surprised me that this isn't implemented. It isn't enough to make me bounce off of it, but if attracting new users is a serious goal, I think "hold to attack" and independent UI scaling would be quite high on the priority list. Related to the latter point, steering new users away from setting their in-game resolution to their desktop's resolution would also help foster new interest, I think. Coming from the world of 2D isometric games like Fallout 1 and Baldur's Gate, I see new users buy these games on GoG with the semi-official resolution hacking tools, they load the game up in their native res, and the experience is wholly ruined. These games (Diablo 1 included) were never intended for characters to look like ants walking across the screen, and having such a bird's eye view really takes the weight away from the art and atmosphere. That's why I was so impressed to see this community already had elegant internal/external rendering options in an easy-to-configure manner. 960x600 internal/2560x1600 external on a 30" is gorgeous and really does take me back to the basement with our 386 (or whatever it was) back when D1 was released. edit: typos, grammar |
Beta Was this translation helpful? Give feedback.
-
|
Would be nice if you could split each topic in its own discussion. Very hard to point specific things about each one here. |
Beta Was this translation helpful? Give feedback.
-
There can be in-depth discussions in the PRs as I make them. This thread is primarily about what features should be PRs at all. Most of the stuff I've worked on I've either made completely for myself (high framerate, right-click to attack, and hotbar made it more much comfortable for me to play the game), or I made quickly for the heck of it because I felt like working on a different feature. |
Beta Was this translation helpful? Give feedback.
-
|
1 and 9 are solid improvements and would attract new users. 2 and 3 are equally important from the standpoint of making certain currently impossible features possible. I think I'd use a dungeon fastwalk option only if it took effect when the level is cleared of enemies. The current concept acts as a "monsters nearby" indicator. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see number 9 and 1 being added. |
Beta Was this translation helpful? Give feedback.
-
|
Throws money at the screen: 1, 4, 11, 13, 16. |
Beta Was this translation helpful? Give feedback.
-
|
I should note that I personally got kind of burned out on working on the lightmapping code, so I think that's the feature I'm personally the least motivated to work on. I feel like I hit a big bottleneck with performance getting so much worse. And the only solution I can think of is implementing OpenGL (or a similar API), but that would involve a lot of work. |
Beta Was this translation helpful? Give feedback.
-
|
I still think what you have achieved is remarkable and would be a waste to throw it all away. I am sure that even if you're not happy witthe results, you have actually paved the way for alternative lighting system that you or someone else might continueat a later point. And the new lighting in my opinion is better than the original. Still it should be probably left for after the completionof hardware mode in whatever iteration it comes. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
So, I've ended up working on a lot of random features but I've finished very few of them. Here are the ones I've done and I'm curious which of these would be fitting for DevX and which ones should have priority.
This is implemented by increasing tickrate but slowing down gameplay.
Work still needed: Implement support for Hellfire monsters and missiles.
Downsides: Due to how I implemented the high framerate it needs to be a multiple of 20. The game is still locked to a specific framerate, so poor performance leads to slower gameplay. During network play, every client needs to run at the exact same framerate.
I replaced nearly all rendering functions with SDL rendering functionality.
Work still needed: Some elements are still in software: main menu, automap, pause menu, and loading screens. It probably needs some code cleanup.
Work still needed: Needs UI hardware rendering to be finished. In-game graphics needs to support all the palette stuff (colour cycling, and "palette swapped" enemies). And I need to do some major code cleanup.
Downsides: Graphically, it just makes the game look worse. It's extremely hard to replicate the way the game does lighting and I think my implementation ends up making it look worse (I implemented this using SDL functions only, so that meant no pixel shaders or other GPU features).
Work still needed: This requires 2. and 3. to be finished. In addition to that, I need to do a lot of work to make this functional for other tilesets. It also needs some major code cleanup.
Downsides: Since I ended up implementing this using SDL functions without access to modern GPU features, I ended up hitting some major bottlenecks which really tanks performance (on my 2080 Super I was getting around 100fps at 1280x720. Using pixel shaders and other features, it could be immensely optimized).
Don't have a video of this, but the feature is self-explanatory. Could be a fun way to do PvP in town, or just a way to test out weapons/spells.
Downsides: Missiles aren't supposed to exist in town, so they go through buildings.
When outside combat, the player will run. In combat, player is forced to walk. I think this greatly improves pacing.
Work still needed: Need to test if this works fine in network play.
Downsides: Purists will write angry tumblr posts about us.
It's a playable cow.
Work still needed: The game randomly crashes, which I guess means it still needs work.
Downsides: Literally none. This is how Diablo was meant to be played.
Moves belt to inventory, and replaces the belt interface on the HUD with a hotbar. With the hotbar you can link any kind of item or spell. When using a potion, it will link to other potions of the same type after using it. When using equipment, they will be equipped. When using spells, they will be equipped.
Work still needed: A lot of misc work is needed to get this fully working, but nothing challenging.
Downsides: Purists will write angry reddit posts about us. Oh, and I have no idea where to put the belt inventory at 640x480 resolution.
This is implemented the same way it works in Diablo 2. When you hold down the button, it will remember what you targetted as you held it down. So you can keep holding it down and you'll attack the same thing no matter what the mouse is.
Work still needed: Normally, the game checks what the mouse is selecting every single tick. This changes that system, so I need to add custom checks for when stuff should get unselected (ie, when an enemy is dead it shouldn't be targeted anymore).
Mechanically, this works the same as "shift + left click" but you can do it with right mouse button.
Work still needed: Add a new skill which is default attack instead of having this occur with no skill equipped.
This is implemented the same way as in Diablo 2.
Work still needed: Depending on the numbers shown, the text isn't always perfectly centered.
Now every player will get reminded each time you're out of mana.
Downsides: Purists will write angry tweets about us.
Work still needed: My current math for automatically placing the map in the corner of the screen is very wonky. It's a bit hard to see the difference between staircases and doors.
Work still needed: More paperdoll variants.
Downsides: DevilutionX will get banned from Github due to excessive nudity.
Using artwork by BillieJoe. Requires hardware rendered UI.
This makes it possible to actually see stuff using cave and nest tilesets.
Downsides: It has a pretty big performance impact. In order to skip shadows I don't render colour index 0, but that means parts of a character isn't rendered since that colour isn't only used for shadows.
Beta Was this translation helpful? Give feedback.
All reactions