[GAME] Space Nerds In Space

12345679»

Comments

  • I had really bad audio quality with my USB headphones yesterday, plugging it in again fixed it. So that indicates that it quite well could have been the device. (different brand then yours)

  • edited April 2020

    I figured out that intelligibility of VOIP is drastically better with some heavy-handed dynamic range compression on the VOIP channels, like threshold of 0.2, limit 0.3, gain 0.98 / 0.3. Boosts it up a lot so you can hear it over the normal audio. Obviously a matter of taste to some extent and that might be too heavy handed, but I made it adjustable. Helps a lot when people are speaking a bit off-mic, or have weak pre-amps.

  • edited April 2020

    Quick demo of planetary lightning effect. Youtube seemed to compress the hell out of the dark areas, so not sure it's very visible on youtube. Oh well.


    Here's a still shot with an exaggerated amount of lightning just to show the effect. It's not quite as convincing in a still shot as when they just briefly flash.

    https://i.imgur.com/KCzfVty.jpg

  • edited April 2020

    Quick update for today, added a warp gate effect, not a big deal, but better than the nothing that was there before. Also, NPC ships respawn at warp gates now instead of at randomly chosen locations.

  • After integrating a pull request from Byron Roosa, Space Nerds in Space now builds and runs on Mac OSX (Mojave) I'm told. You can see the pull request discussion here, there might be some tips about how to build it in there (I don't have a Mac or any knowledge of how things are done on a Mac myself). https://github.com/smcameron/space-nerds-in-space/pull/276

  • The Mac build news is exciting — will take a look.

  • Lately I have been experimenting with porting snis_client from GTK2 to SDL2 (guided by a patch my friend Jeremy wrote 5 years ago.) I have just about everything working except if you resize the window, it doesn't clamp things to a fixed aspect ratio. Other than that, I think everything else is working (of course there might be bugs that I don't know about.)

    With these patches (which I haven't committed yet), this does mean the limited client doesn't exist anymore, which is unfortunate. (Is it possible to use SDL without opengl? I'm not sure. If it is, maybe the limited client can continue to exist with a bit more work.)

    Moving to SDL2 has some potential benefits. Perhaps a windows port would be easier, in case someone wants to try that. Perhaps webassembly might be a possibility.

    For now, the patches are here, in case anybody wants to play with them: https://github.com/smcameron/space-nerds-in-space/issues/277#issuecomment-615894494

  • SDL2 needs a GPU, SDL can do software rendering, but is a pain in the butt to setup for GPU rendering. But it makes porting to windows a whole lot easier indeed.

    Webassembly however, is a pain. It has all kinds of odd things you need to take account of. I think most importantly for SNIS, sockets do not work, as they are "replaced" by websockets. Which I think is a very odd choice (so normal BSD socket calls go to websockets, which are nothing like normal sockets) and your main loop should be differently, instead of an endless loop you need to setup a callback for each loop iteration. And threads do not work. And audio can only be initialized after a keyboard/mouse event in Chrome. And... I guess I missed a few things still :) oh yes, WebGL is picky.

  • edited April 2020

    Ah, if threads don't work, that will be a problem, as snis_client has 13 threads.

    Another idea I had, and even slapped together a proof of concept prototype earlier today was to allow a client to have multiple windows. For remote over the internet play this would be a good thing because you could have your main screen and your other screens in two windows while requiring the bandwidth of only a single client. However, it will require some painful refactoring to do it properly as the assumption that there's a single window is rampant in the code at the moment. I hopelessly broke my proof of concept prototype in an ill-fated too-hasty first attempt at such a refactoring. GTK2 couldn't (or at least I couldn't figure out how to) have more than one opengl window going at a time, but SDL2 can do that reasonably easily.

  • Dev update for 2020-04-19. Transport Contracts, a new font, and SDL2.

  • edited April 2020

    So I've got the SDL port at pretty much parity with the GTK implementation, seems pretty stable, doesn't have any weird oddities that I know of.

    It also doesn't have anything over and above the GTK implementation. And it does mean the limited client will die.

    So the question is, should I proceed with this? It would make a windows port easier, but I'm not doing a windows port (maybe somebody else will, but I won't) so that is a purely theoretical advantage at this point. My multi-window system is so far not panning out (a bit buggy, and less performant than just running two clients) so that's not a real advantage.

    So the question is, do we ditch the limited client on the hope that someone comes along and does a windows port? There's no other benefit from the SDL port, really.

    If you want to try it, there's a branch, "sdl2-conversion-2020-04-22-B", but you'll want to back up to commit 20dd7adfde127450069369706b3fb8867b662bf9 as commits after that have to do with the multi-window stuff that doesn't work so well.

  • edited April 2020

    I tried to give it a quick shot to compile for windows with 20dd7adfde127450069369706b3fb8867b662bf9

    The portAudio stuff isn't very portable, so disabled that, I think you can run portaudio on windows. But makes more sense to hook into the SDL2 audio system.

    I'm getting a whole bunch of "format-truncation" warnings.

    Just hacked up a few extra include paths to find lua and glew includes. At the point where it wants to link, getting a bunch of linking errors to glew and opengl, should be easy to fix.

    As I didn't link yet, I haven't tried running it, and socket initialization needs to be added somewhere. On windows you need to initialize the socket library before you can use it, which is a bit stupid: https://github.com/daid/SeriousProton2/blob/master/src/io/network/address.cpp#L139


    So with the SDL2 port, a windows build looks quite possible, and not that much work. You could build a windows version completely from your linux machine, so you never have to touch windows yourself while still providing a version for a larger user base.

    (Using direct Makefiles reminds me how much I disliked those)


    EDIT: SCRAP THAT. Your make files are not well behaving at it was compiling most things with linux gcc instead of the compiler I set to CC in the Makefile.

  • I know this is just a hobby project, but 30k lines of code in just snis_server.c? Really?


    Things I am seeing are fixable, am getting a lot of printf format warnings. Which is not uncommon when porting code, as printf is a bit messed up in that regard. (for example %hhu is not a valid format specifier on windows)

    Do you want a working windows build? I can put some work towards this, but I need some permissions to do a few things, and don't want my effort to get lost. One of them will be to abstract a whole bunch of socket interactions into a separate file, as there is quite a bit of code duplication in there right now. Or more generally, I would need permission to introduce some platform abstraction "layer". Nothing fancy, just a thin shim between the snis code and direct socket calls, and a few other things. As for example, closing a socket on windows requires closesocket(fd) instead of close(fd)and you always call shutdown before close, so a single function can do both at the same time.

  • I don't know man, it doesn't sound like you would find doing this to be an enjoyable experience at all, so I can't ask you to do it. I mean, you can do what you like, but it doesn't sound like you would like doing this.

  • I don't know man, it doesn't sound like you would find doing this to be an enjoyable experience at all, so I can't ask you to do it. I mean, you can do what you like, but it doesn't sound like you would like doing this.

    @smcameron May I ask how do you got to this assumption? I might be completely wrong, but to me it sounds like daid actually would like to do it. If I understood it right he just asked beforehand if a contribution incorporating some changes would be okay for you.

    Also, it is an open source project, so what would be the reason to contribute other than liking it in some way?

    Sorry for interfering, but it would be sad if some misunderstandings would block an interesting contribution. (Not that it would concern myself directly, as I don't use windows on my devices for a long time)

  • May I ask how do you got to this assumption?

    Well, he's a C++ guy. I'm a C guy. He probably likes C about as much as I like C++. He's already complaining about the code, the build system, etc. It's not a great start.

  • edited April 2020

    To elaborate a bit more, you can't be lukewarm going into a port like this. You've got to be *into* it. This is because the result of such work will be a port that *I* cannot maintain or debug. That means whoever does such a port has to maintain and debug it. Or not maintain and debug it. If you're lukewarm going in, you're not likely to stick around for maintenance. Daid already has EE to maintain, and EE2 that he's working on. So then we end up with an unmaintained port that accumulates bugs as we move on. And this situation would make things not fun *for me*. And if *that* happens, then it's better to not even have a port in the first place.

  • To elaborate a bit more on my side. I'm a bit pissed at work, spend 3 days trying to fix an issue that in the end was a problem introduced by the electronics guy (bad power supply glitching my CPU) so sorry if I come off a bit snarly. Also have a lack of sleep due to kids.

    I very much enjoy making things multi-platform (with the exception of OSX) which is why my new engine runs on Windows/Linux/Android and Web.

    *I* cannot maintain or debug

    That is a choice, not a fact. You could maintain it, at least, up to a "does it compile" level. But it's an important choice. It's the same choice I've made for OSX and MSVC support in EE. I'm not going to put effort in checking or maintaining that.

    I mean, I'm willing to setup the whole platform independence stuff, but if it keeps breaking because you do not care enough to use it. OR, maybe even more important, do not want to be limited by it, then it wouldn't be worth my effort. As I would get annoyed that it breaks often. Which is fine 😁

    Daid already has EE to maintain, and EE2 that he's working on

    Checks local disk... no, I have a bit more then those projects 🧐

  • Quick little demo of a fairly useless new feature. Now you can hold down shift and drag various UI elements wherever you want them. It was easy to implement, so I did.


  • Saw the Git commits for that earlier.

    Can you save those positions and load it on startup somehow?

  • Can you save those positions and load it on startup somehow?

    Not yet, but that would be the obvious next step to make it less useless.

  • Commited a change to allow saving UI widget position changes to a file via a menu on the Demon screen. On startup, this file is read to restore such UI widget position changes. Seems to work alright. If you make such changes, save them, then decide it was a bad idea, you can reset the changes, then save those reset changes to get things back to a "normal" state.

Sign In or Register to comment.