• Oh, validated that multi touch actually works on Android. And discovered that my "screen position to 3D world position" code was still bugged after like 4 attempts. I think I fixed it yesterday, but haven't given it a good spin yet.

    The screen to world position is important to be able to select things on the radar.

    Did I already say that everyting in 3D was 3x as complex? Well, some things are ^3 times as complex...
  • > The screen to world position is important to be able to select things on the radar.

    Heh. The way I do this, is I have a function in my renderer to transform 3d coords to 2D given all the camera data, and I store with all the potentially selectable objects their transformed screen coords (which might be offscreen). Then when checking against the mouse position, I just rip through all those objects and compare to their onscreen coords. I don't try to transform backwards from 2d to 3d (which defines a somewhat hard to understand non-obvious 3D line) and then try to compute point to line distance or something (which should work, but seems harder.)
  • Well, 3D to 2D is: screen_point = world_point * model_matrix * camera_matrix

    Or, in my case: screen_point = world_point * object_position_matrix * inverse(camera_position_matrix) * camera_projection_matrix
    As I do not combine the object and camera positions into a single matrix when sending it to OpenGL.

    Converting the other way around should be a simple:
    world_point = screen_point * camera_position_matrix * inverse(camera_projection_matrix)
    But 1 point does not make a line. So I assumed that, as points have a Z coordinate, I can get 2 points by:
    world_point_a = vec3(screen_point, 0.0) * camera_position_matrix * inverse(camera_projection_matrix)
    world_point_b = vec3(screen_point, 1.0) * camera_position_matrix * inverse(camera_projection_matrix)
    However, this does not work. The point is that the matrices used are actually 4x4, and thus require a vec4. My code simply puts the 4th coordinate always as 1.0, as that gives the results you are after when you are working with 3D coordinates. EXCEPT, when you are doing the inverse of a projection matrix. Then the 4th coordinate is actually the depth into the screen, not the 3th coordinate.

    Once I have the 2 3D points in world space, it's relatively easy to find the point on that line closest to objects or even lines:
  • SCRAP THAT. I was wrong...

    z does set the depth. However, you need to divide the final vec4 by the resulting 4th value from the multiplication to get the proper 3d point.
  • My apologies for relative silence. Have been focusing on event execution (and a home remodel) and haven't been keeping up with this site. I ran another multi-ship event at work recently AND we had our major Scout event this last weekend; 6 fully crewed ships plus mentor/evaluators to conduct scoring and AAR's. Had more Scouts show up than we could sit at consoles. Will provide a detailed write-up soon.

    @daid, am very excited to hear you're embarking on EE2 and that it will have full 3D navigation! Insanely cool. Thank you so very much. Will engage more later.
  • Just a quick FYI, I've posted the latest event writeup...

  • Just excited to know this is still alive. I'm not a coder so I can't help with programming, but if I can chime in on game play elements I will. For starters, I hope there will be some interface with the USB DMX controller in EE2. I know that's way down the road but that's all I can say right now.

    That and the hacker station was cool but needs to be more impactful next time. Minesweeper 4 life!
  • Something I have been thinking about for a long time already. And this also effects EE1.

    Currently EEs client/server architecture is quite simple. It's a star network. 1 server and all clients are connected to the server. The server sends updates to all clients, and clients send "requests" back to the server to indicate changes that they want to make.

    This works really well. So nothing I want to change there. But, when you have an internet game, you have a server on one side, a "long/slow" internet connection and on the other side you have 5 or 6 clients.
    Now, the server sends all clients exactly the same data. There is no distinction being made between clients. Same is true for the requests from the clients, there is no distinction in from which client data comes.

    Which makes me come up with the idea that you could have a "tree" network. A server on location "A", 5 clients connected directly to the server on location "A". 5 clients on location "B", 1 client is connected to the server trough the internet, and the other 4 clients can just connect to the primary "B" client.

    This would reduce internet bandwidth of the server by a lot, as it only needs to update a single client, instead of 5 of them. And it makes it easier to connect most of the clients, as only 1 client has to enter the IP address. The rest can use local server discovery to connect.
    But I'm wondering if it's worth the added complexity. I mean, internet games seem to work quite well at the moment. I haven't really had reports of issues there...
  • How much bandwidth does a client use?
  • Depends on the scenario. But if I remember right, between 1-2kb/s usually.

    Pressing "F10" will show the network usage as well as FPS.
    Oh, and "F11" will show detailed FPS timing graphs, so you can see where time is spend, on rendering or updating the game or other bits.
  • A shoddyer residential connection with an up speed of 128 kbps would be able to host 60 clients. You won't be saving much bandwidth for the added complexity. Save the tears for something else such as....

    I was playing fibbage by Jack box games the other day and was amazed at the simplicity it was to just join in and play. The jist of those games is a console or PC is connected to the TV and serves as the main screen for the trivia game. Everyone played on their smart phones by loading the website jackbox.tv in their mobile browser and entering the game code shown on the tv. No apps to download so the barrier to entry is really low.

    I feel like this is missing from this genre, where the game server also serves a simplified, phone sized web UI for simpler, shorter crewing.
  • edited September 2019
    I've thought about a web UI, I've even toyed with it for EE2. But I came to a simple conclusion. I don't like html and javascript. So I see the value. But I most likely won't do it.

    Also, you might be mixing up bytes and bits. Speeds from providers are generally specified in bits/second, while my data per client is in bytes/second. Still, that's up to 8 clients. So you are right, little gain there.
    It's my embedded background, always checking to optimize a "scarce" resource.

    Back to the jackbox thing. I do like the matchmaking/joining process. Simple ~5 letter code to join a game. No messing around with ip addresses, port forwarding, creating passwords or searching your game from the list. Just start the game and play.

    Now, jackbox does have the advantage that they have very little data to communicate, so their "switchboard" server that they have to handle this only has a bit of bandwidth required per game. Serving the images and stuff actually requires more bandwidth is my guess.
    However, we have the "advantage" of very few players and games running at all times. So the bandwidth requirements for a switchboard server won't be high overall.

    It does add ping time, for example, if you are in the US, using my home server as a switchboard (which is located in the netherlands) will add 100ms ping time. New zeeland seems even worse, with 300ms ping time. So it might be good to host more then one switchboard server.

    So I might end up with still requiring a download+install. But joining a internet game could be just entering the 5 letter key that is presented on the server.
  • I'm not a fan of html/javascript either. I'm just a hobbyist with no formal training and I ran crying back to my simple python scripts when I tried to make a web-based mars mission simulation game for my astronomy class.

    Does EE2, or EE1 for that matter, have enough of an api where someone could make a server plugin for such a feature? How hard would it be to add in support for various scripting language of choice?

    Yah I didn't see the bits vs bytes. If someone really wants to host an internet game on a shoddy connection it will probably be worth it to spin up a $5 VPS in their region for a headless server. Linode and Digital Ocean services just charge a fraction of a cent per hour so personal costs can be low. Run it in a docker container, or whatever these kids use these days, and it can really be platform agnostic.

    My personal interest isn't in internet play but more casual settings. Until everyone else bought jackbox I was asked to bring my switch to our gatherings. I'd just plug it into the tv when we wanted to play and just we just go. My hypothetical dream would to be asked to bring "the spaceship game," bring my rpi4, plug it into their tv and we would have a short session or two using our phones as a controllers. A little qr code or something similar on the screen to make joining easier. (Heck if it did run on a pi it could be configured as its own wifi hotspot, making it a fully self contained bridge game)
  • Heck if it did run on a pi it could be configured as its own wifi hotspot, making it a fully self contained bridge game
    EE1 runs on the PI2/PI3, but not very efficient. I think the PI4 has quite a good chance of running it decently, as that has a faster GPU. But I don't have one, so no idea how well that works.
    (you need to enable the "experimental" OpenGL drivers in raspi-config, other then that, it works like a linux config)

    The rendering part is the biggest issue for the PI, the rendering of the GUI isn't very efficient. EE2's rendering is build from the ground up, and has lower system requirements. And thus will run better on a PI.

    With the return of the android build. You could actually play with just a pi and a bunch of android phones.
  • edited September 2019
    EE2 will have a websocket API for fast realtime interfacing to the game. This will make building web based interfaces possible. EE1 only has a http interface, which will depend on polling. It can access a lot of things to make a web based user interface. However due to the polling it might be a bit slower in response times.

    The websocket server for EE2 has already been build:
    That's why I say it will have that :-)

    So, EE2 will have support for web based stations, but I won't build the html/javascript part myself.
  • edited September 2019
    I held back this post for quite some time, because I did not want to derail the thread, but I will mitigate by posting content more on-topic afterwards
    Some games lack this meaningful decision aspect at all. If there is only a single path forwards, no difference between decisions you make. Then you have a story (movie/book) not a game.
    I hope this will not derail the thread, but IMHO you can make meaningful decisions even if the game itself is linear. I don't know Bioshock infinite, but in Soma for example, you have to make many major decisions, but there is only a single ending and the decisions only have a minor, if any effect for the game's story. However, almost all of them were meaningful IMO. Simply because you as the player know what you did. Sometimes you can find information that will put your decision in another context. But the game does not judge you, that is up to you. And that works pretty well here.

    On a bridgesim level: Game-mechanic wise, there is a simple, optimal solution of the Kobayashi Maru test: Ignoring the distress call will "only" lead to the destruction of the KM, vs destruction of KM+destruction of own ship + causing an interstellar incident. But I guess for most captains, this decision will still be very meaningful.
  • edited September 2019
    I feel like this is missing from this genre, where the game server also serves a simplified, phone sized web UI for simpler, shorter crewing.
    There are at least two bridgesims around that allow full stations through web.
    - Star Ship Horizons, however it requires at least one windows computer as the server.
    - Thorium is based on node.js for the server and HTML5 for the clients, so pretty much plattform independent. However it is different than most other bridgesims and "narration-driven" instead of "game-mechanic-driven"
    EE1 only has a http interface, which will depend on polling. It can access a lot of things to make a web based user interface. However due to the polling it might be a bit slower in response times.
    It should at least be enough to rebuild the engineering station in html5. Real time is not as important as on other stations, and it does not need information of the game world state.
    EE2 will have a websocket API for fast realtime interfacing to the game.
    Cool! BTW also interesting that you now have chosen SDL2 for EE2, as that was not among your considerations in the "pondering" thread. But it is surely a good choice and well supported.
  • Cool! BTW also interesting that you now have chosen SDL2 for EE2, as that was not among your considerations in the "pondering" thread. But it is surely a good choice and well supported.
    Choice was simple. I've used SDL1.2 before, and had little issues with it. Support for SDL2 is awesome (being backed by valve).

    Compared to SFML, which I used for EE1:
    SFML provides some more text rendering and other rendering features, however, in the end, those proved to be quite inefficient to work with. For example the text rendering makes it a bit unneededly complex to align text properly. And line wrapping is a hell as well.

    The text input from SFML is broken. Simple as that. Numpad keys are not properly separated from number keys for example.

    SFML doesn't support multiple application windows or multiple monitors. SDL2 does. SeriousProton2 does. This should allow for better multi monitor setups, where you can have 1 monitor running the main screen while another monitor runs a specific station.

    Android support of SDL2 is better then SFML. Quite a few of the EE1 Android bugs are a direct result from SFML Android being a hack. SFML forces android to OpenGL ES1.1, with SDL2 I force Android into OpenGL ES2.0 and use Desktop OpenGL 2.0 every where else. There are very few differences then, and thus compatibility in rendering is easier to maintain.

    Dependencies. SDL2 has no dependencies. SFML uses quite a few libraries, adding complexity in the build system (especially if those dependencies change)

    Gamepad support. SDL2 detects "xbox" like gamepads and provides a uniform interface. While SFML only provides the joystick interface, which makes adding a default button mapping pretty much impossible. (Less important for EE2, but I still like it for other things I'm doing with SP2)
  • Interesting news:

    Only tried this with chrome on windows so far. But the above first link is my 2 player mario clone game, normally running on the RaspberryPI on an Arcade cabinet. Using SeriousProton2 engine.
    Now, with a few patches to the engine, I got it to work with https://emscripten.org/ simply put, allowing for native C++ code in the browser.

    Audio isn't working, something to do with trying to start audio before user interaction. Something that can be fixed I guess.

    Now, why is this interesting, this means EE2 might have browser support. I don't know if the network socket functions work. And I notice few other minor bugs as well, nothing that makes things unplayable, especially in the Mario clone.
  • Cool! BTW on Firefox there is sound, maybe this Information helps.
  • Oh, yes, most likely. Chrone has this:

    It won't allow audio till do have some kind of user interaction. So if you click on the page in chrome before all data is loaded, it will play audio.
  • @daid Let me know when you're ready to consider interface design. I'd love to take a crack at v2!
  • edited October 2019
    @Interesting John I will. But progress is very slow. I get distracted with other things.

    Like, I have been working on a few changes...

    Ok, it took a whole bunch of commits. But now, I have my multiplayer code working in both direct connections, and by the means of a "switchboard" that acts as a gateway to connect multiple different locations in the internet together. With as bonus, the code detects that you are on the same local network, and bypasses the switchboard if you are still attempting to use it.

    Oh, and these switchboard connections use the websocket protocol, and thus push trough pretty much any firewall with ease. And optionally can use encryption (but I didn't test that part yet)

    While this isn't any direct progress on EE2, as I have been doing this in side projects. There is a direct win for EE2. And the whole multiplayer code is getting a lot more stable now, as I'm finally testing and using that.
    That is something very few people know, but the first versions of EE didn't have the stable network code that it has now. Initially the code had a whole bunch of bugs that caused disconnects or desyncs.
  • Yeah, I get distracted with other work and projects too, haha. But I keep an eye on development on the current EE, so I'm keen to follow and help v2 where I can as far as design and UI/UX go.
  • Will the new version need a better processor ?
    Just asking cos I am running my current setup on a i5 server and 5 quad core atom laptops, and it works great, The keybindings are what I'm looking forward to so I can make custom consoles. Steampunk in space anyone ?
  • You'll be fine. We're running on lesser hardware. I'm an embedded engineer by trade, I work with very limited CPU and memory by default. I'm also targeting Android, which has less power then that as well.

    EE1 has keybindings, they just don't work as well, only allow keyboard bindings (not mouse/joystick/gamepads) and are a bit more hacked into it.
  • Yeah, I get distracted with other work and projects too, haha. But I keep an eye on development on the current EE, so I'm keen to follow and help v2 where I can as far as design and UI/UX go.

    Well, on the UI side. I am not an expert (as EE1 shows)

    But I like the look of this: https://img.itch.zone/aW1nLzE4OTQ3NTMuanBn/original/IRvb/I.jpg
    (from https://auburnsounds.itch.io/graillon, actual application unrelated, just the UI look)
    With the look of the analog sliders and dials. Gives it a really "nuts&bolts" look.

    But a much more sci-fi look like this:
    Is also nice.

    It will also be much more easy to customize. For example, I want a slider, rotation dial and manual number entry to be 100% exchangeable with each other. As well as other "data display" components.
    Example, you have the freedom to turn the EE1 power/coolant screen. Which is now filled with sliders and progress-bars. And then turn it into a screen filled with rotation dials and analog meters like you would see for your fuel gauge in your car.

    At the core of this, there is the "gui" files. This system is already quite developed, and I've used it for a few other small games that I worked on. Example gui file for a level select screen of a mario clone:
    This removes the UI definition from the code as it is now with EE1.

    It's not as powerful as html+css, or Qt QML. But it provides quite a bit of flexibility compared to the old system.
  • That code definitely reminds me of CSS, which I'm very familiar with. Since the main interface is usually touch screens, a more sci-fi design makes sense, though I could see why you like the more analog look :)
  • edited October 2019
    daid said:

    EE1 has keybindings, they just don't work as well, only allow keyboard bindings (not mouse/joystick/gamepads) and are a bit more hacked into it.

    There is, however, a PR made by Amir Arad that adresses the joystick/gamepad part: https://github.com/daid/EmptyEpsilon/pull/656. Any chances for that to get merged, or are there major issues with that one?

  • Big chance I can merge that. I sometimes lose track of pull requests, especially if they are quite big like this one.

    However, there is a major difference between that pull request and the sp::Keybinding of SeriousProton2. That pull requests add the option to rebind joystick axis and buttons. But as a separate system.
    The sp::Keybinding from SeriousProton2 has a unified interface. The code sees no difference between a keyboard button, a mouse button, mousewheel rotation, gamepad button or a joystick button. And you can even bind joystick axis to "button presses". So even if "activate jump drive" is a button, you could bind a joystick axis to it, so that when you push the joystick forwards it will activate the jumpdrive.
    As well as vice versa, actions that can have analog inputs, like rotating with the joystick can also have buttons bound to it, which then act full on/off.

    It also supports binding multiple keys to the same binding, and multiple bindings to the same key.
Sign In or Register to comment.