search

fgsfdsfgs / vitaXash3D

a port of Xash3D-FWGS to the PSVita
GNU General Public License v3.0
146 stars 15 forks source link

Congratulations and some suggestions to you #2

Open a1batross opened 6 years ago

a1batross commented 6 years ago

At first, I want to congratulate you with new engine platform port. :)

I saw you put in README some issues, so I may give you some points with resolving these:

I recommend you to rebase on current master branch from FWGS/xash3d, so you can send a PR with Vita support to the upstream engine code, when it will be ready. :)

a1batross commented 6 years ago

Saving can be slow, because IO. Maybe it's not related to case-insensitive emulation, and there is just slow write() syscall?

fgsfdsfgs commented 6 years ago

Hello and thanks a lot for your suggestions. I built the port on top of v0.19 because I thought it would be easier to port a stable version, but now I wish I hadn't, since there will be much to fix during a rebase. I'm afraid it's not possible to integrate Vita support cleanly into upstream Xash yet, since it's pretty much hacked in with #ifdefs all over the code. This had to be done because the Vita environment is a lot different from any other platform Xash currently supports, for several reasons:

  1. Vita environment is not fully POSIX-compliant. For example, there's no concept of current directory, so I had to hack in base paths everywhere.
  2. Vita has no dynamic linking. There's some kind of module system, but I haven't looked much into it, and it looks mostly similar to how Linux kernel modules work, so it's probably not very useful. This means game and UI libs have to be hardlinked to the executable. I saw that you added a special #define for such cases in upstream Xash, but hardlinking still requires a lot of hacks to get rid of repeating symbol names and such.
  3. vitaGL is not even fully GL1.1 compliant, requiring stubs for some GL functions and/or disabling or rewriting several chunks of renderer code.

All this would require some work to resolve, so I think I'll focus on making everything work on the Vita first. Before all this is resolved all I can do without much trouble is backport particular commits from upstream.

As for your suggestions:

  1. There are definitely some blending mode inconsistencies between vitaGL and regular OpenGL, I'll have to look into that.
  2. All rendering is currently done through vglDrawObjects, which is similar to glDrawElements, but works slightly differently internally. Immediate mode GL functions (glBegin, glEnd, glVertex...) are somewhat broken in vitaGL, which is why I had to use it everywhere.
  3. I'm using the glDrawElements model renderer, I haven't even touched the legacy one. Maybe it could be faster.
  4. I have set SOUND_DMA_SPEED to 48k, but I didn't think to add a new resampler, thanks for that.
  5. I'll backport the deadzone control, thanks.
  6. The input code indeed uses Joy_AxisMotionEvent. I noticed that the axes could be remapped only after I wrote that issue. The buttons send Key_Events for hardcoded keyboard keys, though.
  7. I'll look into FS_FixFileCase, thanks for the tip. But it seems that it is indeed the writes themselves that are slow. There used to be a bug in VitaSDK's I/O implementation that made them really slow, but it's supposed to be fixed. I also had to enable XASH_ALLOW_SAVERESTORE_OFFSETS, could that also affect the speed?

The renderer could also be sped up significantly by using custom shaders instead of vitaGL's general purpose built-in shaders that are quite slow. This is already on my to-do list.

Also, I suggest that you guys refrain from using enums in structures that are read or written to or from buffers and files, because for certain platforms (Vita being one of them) -fshort-enums is enabled by default in GCC, which caused me a lot of grief.

a1batross commented 6 years ago

I see some advantages to you to move on current master branch: 1) 0.19.1 thought to be a next major release, but we don't moved to new protocol yet. So 0.19.1 isn't a minor release, it contains many new features and optimizations(which may ne handy to you) from total 300 commits. Or more, I don't count :) 2) I see you don't preserved git history. Git is a very powerful tool, especially in patch handling. So even if you will fall behind from upstream, Git will do best possible rebase for you. And it's easier to me to merge your branch into upstream.

I don't insist to move now. I just suggest you to do it when you consider it necessary.

Although we stop porting engine to new platforms, patches for non-posix environment will be great, which means easier console ports in future. :) Dynamic linking does not exist on many console platforms. Sometimes it's possible to write your own dynamic linker, sometimes it's not, due to platform issues. Xash3D have already some workarounds for Emscripten, which doesn't handle dynamic linking completely. We maybe need to provide a common way for such platforms. Buttons are not hardcoded. They are translated from system keys, i.e. keycodes, to engine-side keys.

Yes, I am aware about enums and crossplatform. I'm trying to avoid it in network or file structures, but there is too much struct definitions which came from Unkle Mike's engine. I am afraid to change them even if they are meant to be a 32-bit integer without a serious reason.

fgsfdsfgs commented 6 years ago

You see, I started this as an experiment to see if a Xash port would even be possible for the Vita. I just grabbed the 0.19 source ZIP and started working on it with no hopes of success, which is why I didn't even think of making a proper fork. I will move it sooner or later, just saying that it isn't probably going to happen very soon.

As for hardcoded buttons, I meant that Vita gamepad buttons are mapped to engine keys, and those mappings are hardcoded and cannot be changed with configs, i. e. X maps to Enter, Start maps to ESC, etc.

a1batross commented 6 years ago

It doesn't need to be configured. Engine have a good key binding system, where keys are mapped to appropriate console commands.

You may use K_AUX keys, which is preferred way, as it's intended for using on gamepads(but there is no default mappings for them), or just map them to keyboard keys and have default mappings.

25 февр. 2018 г. 22:14 пользователь "fgsfds" notifications@github.com написал:

You see, I started this as an experiment to see if a Xash port would even be possible for the Vita. I just grabbed the 0.19 source ZIP and started working on it with no hopes of success, which is why I didn't even think of making a proper fork. I will move it sooner or later, just saying that it isn't probably going to happen very soon.

As for hardcoded buttons, I meant that Vita gamepad buttons are mapped to engine keys, and those mappings are hardcoded and cannot be changed with configs, i. e. X maps to Enter, Start maps to ESC, etc.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fgsfdsfgs/vitaXash3D/issues/2#issuecomment-368336043, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgf7iE-lsSEoF73F2DPeJXbzrD2Waks5tYbEngaJpZM4SSPgP .

fgsfdsfgs commented 6 years ago

Do you guys have an IRC channel or something? I'd prefer a more convenient way of communicating than Github issue comments.

a1batross commented 6 years ago

We have a Jabber conference, Discord server and VK conference. We had IRC before, but it was forgotten, because no one joined channel.

a1batross commented 6 years ago

Oops. Forgot to add link to Jabber conference. It's most international-friendly way to communicate with other engine's developers. fwgs@conference.jabber.ru