Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choosing graphical backend #1

Closed
sskras opened this issue Aug 3, 2018 · 3 comments
Closed

Choosing graphical backend #1

sskras opened this issue Aug 3, 2018 · 3 comments

Comments

@sskras
Copy link
Contributor

sskras commented Aug 3, 2018

@ApertureSecurity in diasurgical/devilution/issues/149 wrote:

What libraries are you wanting to use? I was thinking SDL2 could be a simple library to use.

FWIW, I googled for DirectDraw-to-SDL conversion after the question. This is what I found:
https://www.gamedev.net/forums/topic/287518-porting-a-game-from-directdraw-to-sdl/#comment-2808684
https://www.gamedev.net/forums/topic/280911-porting-directdraw-to-sdl/
https://discourse.libsdl.org/t/any-tips-on-porting-from-directdraw-to-sdl/9111/2
http://forum.pj64-emu.com/showthread.php?t=5283

I guess there are several approaches by going this route:

  • writing wrapper functions / methods;
  • conditionally defining a blocks of sensitive code (using #ifdef);
  • rewriting (reducing) the original code directly (in place);
  • adding some layers of abstracting to the DDraw API;
  • rewriting all the graphical code from scratch.

@galaxyhaxz replied:

I was thinking OpenGL would be the best route for graphics, and OpenAL for sound. We could probably use SDL for input.

@ApertureSecurity also added:

Ok. I have had this conversation before and every time it went from SDL -> SDL2 -> OGL -> GLFW -> Death....

I am leaning between OGL and SDL2 . I like the idea of SDL2 because we have work already done using this for Diablo. I looks decorated enough that it might make good for quick use and it's the only one of these that I have some little experience using SDL2.

I will look at OGL though and maybe it is the better of the few.

Regarding DirectDraw-to-OpenGL conversion. For some reason I can only think of a wrapper like wined3d, but it's X11 specific. Well, others exist, but all are Windows dependent:

So if the project is to follow approach other than rewriting everything, then maybe it would make sense to put effort into porting one of these Windows wrappers to other platforms.

@ghost
Copy link

ghost commented Aug 6, 2018

Good day @sskras I am not sure why I am just seeing this now. Thank you for the open issue.

These links are usefull actually.

It's been a few years since I have written anything in C so I think this will be a bit of fun. I will keep this open for a bit.

The problem is that the wrappers are probably compatible with windows and my objective is to be able to use the code in any platform.

ghost pushed a commit that referenced this issue Aug 8, 2018
readme: update credits to authors of sanctuary
@AJenbo
Copy link
Member

AJenbo commented Aug 24, 2018

In regards to SDL vs OGL, SDL can give you a OGL context and it's probably the right solution for input and window management any easy so go with that, and if at some point you find a good feature that can only be achieved with OGL you can start rewriting that part for it.
In any case you would be bending OGL to your task since it's not targeted at 2d sprite games so probably it would also be easier to do things in SDL. This is probably also why you see a pattern of projects ending once they go down that route

ghost pushed a commit that referenced this issue Oct 2, 2018
@ghost
Copy link

ghost commented Oct 13, 2018

We have this in SDL2 already .

This will be completel soon.

Cheers

@ghost ghost closed this as completed Oct 13, 2018
AJenbo pushed a commit that referenced this issue Mar 16, 2019
* CheckIfTrig bin exact

* CheckIfTrig bin exact suggestion #1

Co-Authored-By: qndel <stefan551@o2.pl>

* CheckIfTrig bin exact suggestion #2

Co-Authored-By: qndel <stefan551@o2.pl>
AJenbo pushed a commit that referenced this issue Mar 16, 2019
* GetMissileVel bin exact

* GetMissileVel bin exact suggestion #1

Co-Authored-By: qndel <stefan551@o2.pl>

* GetMissileVel bin exact suggestion #1

Co-Authored-By: qndel <stefan551@o2.pl>
AJenbo added a commit that referenced this issue Mar 24, 2019
Co-Authored-By: qndel <stefan551@o2.pl>
AJenbo added a commit that referenced this issue Mar 24, 2019
Co-Authored-By: qndel <stefan551@o2.pl>
AJenbo pushed a commit that referenced this issue Sep 26, 2019
AJenbo pushed a commit that referenced this issue Sep 26, 2019
@Chance4us Chance4us mentioned this issue Nov 11, 2019
Lundar pushed a commit to Lundar/devilutionX that referenced this issue Sep 6, 2020
AJenbo pushed a commit that referenced this issue Mar 23, 2021
Single-player difficulty selection was implemented in a very hacky way.

Documents what's going on there and fixes a memory leak.

Memory leaks that this fixes looked like this:

```
Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x7f435b789f17 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.6+0xb1f17)
    #1 0x5567766c62b8 in dvl::selgame_GameSelection_Select(int) ../SourceX/DiabloUI/selgame.cpp:163
    #2 0x5567766d8ee8 in dvl::selhero_Load_Select(int) ../SourceX/DiabloUI/selhero.cpp:464
    #3 0x5567766d6ed1 in dvl::selhero_List_Select(int) ../SourceX/DiabloUI/selhero.cpp:325
    #4 0x556776692683 in dvl::UiFocusNavigationSelect() ../SourceX/DiabloUI/diabloui.cpp:396
    #5 0x55677669158e in HandleMenuAction ../SourceX/DiabloUI/diabloui.cpp:223
    #6 0x5567766917b9 in dvl::UiFocusNavigation(SDL_Event*) ../SourceX/DiabloUI/diabloui.cpp:277
    #7 0x556776695dff in dvl::UiPollAndRender() ../SourceX/DiabloUI/diabloui.cpp:626
    #8 0x5567766d94ef in UiSelHeroDialog ../SourceX/DiabloUI/selhero.cpp:512
    #9 0x5567766d997f in dvl::UiSelHeroSingDialog(int (*)(int (*)(dvl::_uiheroinfo*)), int (*)(dvl::_uiheroinfo*), int (*)(dvl::_uiheroinfo*), void (*)(unsigned int, dvl::_uidefaultstats*), int*, char (*) [16], int*) ../SourceX/DiabloUI/selhero.cpp:547
    #10 0x556776a44f45 in mainmenu_select_hero_dialog ../Source/mainmenu.cpp:98
    #11 0x5567765f9f15 in SNetInitializeProvider ../SourceX/storm/storm_net.cpp:102
    #12 0x556776c996b9 in multi_init_single ../Source/multi.cpp:826
    #13 0x556776c98b1e in NetInit ../Source/multi.cpp:770
    #14 0x5567767d0c0b in StartGame ../Source/diablo.cpp:375
    #15 0x556776a4493d in mainmenu_init_menu ../Source/mainmenu.cpp:45
    #16 0x556776a44c05 in mainmenu_single_player ../Source/mainmenu.cpp:61
    #17 0x556776a454a9 in mainmenu_loop ../Source/mainmenu.cpp:152
    #18 0x5567767d2892 in DiabloMain ../Source/diablo.cpp:602
    #19 0x5567766e3c69 in main ../SourceX/main.cpp:34
    #20 0x7f435a69ecb1 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28cb1)
```
tukkek pushed a commit to tukkek/turn-based-diablo-1 that referenced this issue Oct 16, 2024
Turn based mode, initial commit. Press 'p' for enable command pause.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants