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
[Feature Request] MP4 and OGV support for cutscenes, iqm/md5 model support and .wal +Md2 moved to legacy support #4
Comments
Md3/md5/IQM formats is already discussed in yquake2/yquake2#887, yquake2/yquake2#650, yquake2/yquake2#607 and yquake2/yquake2#605. Support of md3 format is possible but requires or rewrite render codes for all renders or convert md3 to md2 format on fly before loading, like example https://github.com/yquake2/ref_vk has bigger list of supported model MDL/FM/dkm formats by on fly convert. Other formats do not use frame number for animation, instead format uses string names for animation steps and support of such animation will require rewrite while protocol between game library and renders. Textures and videos is not limited by a color map, modder could could use hi-color textures without wal equivalent or convert image format to different color space, as example heretic2 m8/m32 is supported without limitations. It's correct that current code support only videos in quake2 format, but add smacker video format requires several lines of code change if someone has mod with smk video, I could share such code. About ogv/theora video support, its technically possible but requires to search small library with good licence like MIT/GPL. And small/embedded is highly important. MP4 is a proprietary format, quake2 could not be linked with the such code in most cases. |
@Bittermens could you please share example of open-source mod with md3+ models based on idtech2 like engine? I like to look to implementations, maybe it has some good ideas to port. |
@Bittermens I could look into implementing .webm for you if that would satisfy. |
Let's wait comments from @Yamagi and @DanielGibson before create new code
I could be wrong, as I know webm is much more complicated than theora and has much bigger pile of code, as result it will require additional code library linking. It also adds additional question for hardware acceleration video decoding, use libva/ffmpeg/directx and so on. @Rykita Could you please describe little more about your idea of implementation? |
I think Smacker would be okay, because there is at least some kind of use case for it and it shouldn't be too invasive. But please let's not add highly invasive features like MPEG codecs (would require a dependency to ffmpeg) or md5 model support (would require rearchitecturing in the renderers and might break the client<->game API). We must keep in mind that Quake II has a rather fragile code base and every new feature, regardless how well-meant it is, makes it more complicated, adds new bugs and problems, often with very little gain for our goal to preserve the game. If someone really needs these features for some kind of modding project or total conversion it would be better to implement them in a fork which isn't limited by nearly 100% backwards compatibility to Vanilla Quake II. |
I have created yquake2/yquake2#1025 with smacker support, it does not support compressed audio and always use first track from video. Smacker has support up to 7 tracks in single video, I have only examples with single track, I suppose it should be enough. Support of compressed audio is limitations of libsmacker, I suppose that compressed audio is just rare case for old games. Support of RoQ format from quake3/doom3 is also possible, but I have not checked it. It will be bigger change in logic because it uses 24 bit colors instead pallette, but support code should be also small. |
Sorry for being late since i am diddling with battlezone too. For Md5 as all as i can think of it Quake Remastered mods making full use of it like the lego Quake mod, which is literally one of the best funny mods i saw in years. As for Md3 i can only think of KmQuake2 mods at playground.ru which also includes milous mods, which not only makes full use of md3 and md2 but also the texture that really pushes the engine into Quake 3 and idtech 3 area, though they make full use of the original lazarus into levels seen only in 2010's og quake mapping once they got rid of map limits and gave birth to Nyarlathotep, Altar of Storms and Arcane Dimensions. |
The question is: If we add another video format, which one gives us the greatest gain in terms of adoption without being too invasive? I mean, whatever we add, it will be used only by very few mods. Likely not even new mods, because the Quake II modding scene is more or less dead at this point. Just existing mods. |
RoQ looks as best solution, it has encode/decode support in ffmpeg, and anything supported by ffmpeg could be converted to it. In same time RoQ format support requires one additional call to render with 24bit color and need to check fps limitation for movies, RoQ has 30 fps by default, cin has 15fps by default. I suppose it can be only new mod, as noone use RoQ for q2 mods as see. Or someone just likes to replace initial ID logo with new one from doom3. |
Also as idea we can extend sprites support inside of game with usage cin/RoQ as animation. |
About the videos |
From a new mod perspective if you are looking to extend q2 with features from q3 or other engines you may as well start with q3, when if you look at the two codebases side by side, you will see q3 is a refinement on q2. I'd like to see sprites added back into q2, they are supported but rarely used. |
Q2test supported sprites explosion also Q2test had better shaded monster textures than release |
But the point still stands: Adding features for features sake makes the already fragile source even harder to maintain. And features which are there but not used by anyone tend to bitrot. They break by other changes, no one notices until month or even years later someone complains. And like @apartfromtime says. If someone wants to develop a new game it's better to start from Q3A itself or even better RTCW or Jedi Outcast. If it must be Q2 fork YQ2 or KM2 and implement the needed features by yourself. YQ2 was never indented as a engine for mods, our goal was and is to preserve Quake II. If we want to support modern cutscenes like that remake of the intro video, ROQ is more or less the only option. Smacker is too limited for todays video standards. We don't want external dependencies which rules ffmpeg out. And even if there was a simple implementation of a modern codec there is the still the software patent problem and MPEG license situation. Even Theora is rather complex and hard to implement without importing a lot of code. A Quake II Remastered will likely launch soon - https://www.bluesnews.com/s/261090/quake-ii-remastered-gets-korean-rating I think it's a good idea to wait how it's implemented. Quake I Remastered wasn't that different, it just added a new model format. For Quake II they'll need to come up with a solution for the videos. Adding these formats to YQ2 - if possible of course - would add real value. |
I don't want to give into hope, last year broke me hard and even Q1R got forgotten. |
@Yamagi what do you think about PNG/JPG support in cl_cin code as part of |
Since we alreardy have the decoders and it should be rather easy: Go for it! |
Done :-), I have removed smacker commit and added r_retextururing. I will make vulkan changes after merge. |
I have finally merged the pull request. |
Thank you! I have applied patch to ref_vk Smacker support example will live in https://github.com/0lvin/heretic2/blob/b27fe4f6/src/client/cl_cin.c#L811 |
It looks like Q2 Re release uses:
|
TGA, rather. PNG is only used for the
Also
Apparently they recompiled the maps (except Q2N64's) at 8:1 lightmap scale instead of 16:1, but the WALs aren't double-resolution, so there might be some additional something somewhere. Lightmaps also aren't rotated when textures are rotated. |
I wonder if they fixed the broken precalculated visibilty sets.
md5 might be problem. Otherwise it doesn't sound too bad. Especially Theora instead of something patented by MPEG-LA is a good choice. |
In ware2, yes. |
MD5 in remastered pretty much opened the door for non vertex animations, interesting that they said that isn't kex but q2 engine itself that could support that. also the polycount number under it is pretty much limitless |
It looks like the footstep sounds should be straightforward to implement. The reverb stuff is going to be more complex of course, given the backend differences, and the lack of engine code source availability. Q2EX uses the file Also, mentioning #3 so these issues are linked on GitHub. |
Additional difference:
|
I have applied changes for lightmaps for maps for vulkan render, ReRelease uses different structure for lightmaps and need to implement DECOUPLEDLM yquake2/ref_vk#47, model still has light issues in same time. |
I have created separate branch with all improvements for ReRelease version: https://github.com/0lvin/yquake2/tree/rerelease-combined Additionally to yquake2/yquake2#1040 it has fix for wall lightmaps in Vulcan and GL1 render and fix for sky rotating. Model lights are still wrong in all renders. Update: base2 does not have lift to second floor. When I have tested with q2pro lift exists and lights are much better. Also current code can't load/render mguhub map. |
I have applied all my changes to yquake2remaster. Old links to my changes are not relevant any more @Yamagi look like this issue also should go to yquake2remaster repository. What do you think? |
I have moved the issue to the yquake2remastered repo. |
@Yamagi thank you!
Base2 issues related to use map fixes by ent file, filles should be regenerated for new maps versions. Update: All renders has visual glitches after load mguhub map. Additionally none of render could render model light in base1 map. Additionally GL3 and soft has issues with wall light. Soft render in all maps has visual glitches same as in original borehole map. |
Map fixes shouldn't really be necessary for the remaster maps (atm), anyway. QuakeSpasm has a system wherein ENT files are versioned using a 4-digit CRC (ex: |
@SirYodaJedi thank you, I will check. Current state: |
Latest code in master has support of BSPX lightmaps and octree lights, and QBSP map format for GL1 and Vulkan renders. It's not best of the best implementation but enough to start checking Q2 ReRelease maps. I have marked in readme what maps loading I have checked. |
I have rechecked all mgu* maps, all maps could be loaded in gl1/vk renders except one . It does not mean that all functionality is worked, but enough to load. mgu5m2 requires to change MAX_MODELS value that will break backward compatibility. RR code have used translation function, and i have not found good solution how to apply it with minimal regressions. Also maps requires monsters codes from https://github.com/yquake2/xatrix and other addons. I am looking to take code from original folder of RR until yquake2/xatrix#96 and yquake2/rogue#122 are not closed. Note: looks like zaero is not in the list of rereleased codes :-( Checked with 83a3197 commit. |
f83d40f has ogv/roq format cutscenes support. |
Early alpha release windows binaries: yquake2remaster-8.21RR1.zip |
Zaero isn't an official expansion so it wasn't our call. Might be a good idea to try to reach out to the original developers to get them to re-license it under GPLv2. EDIT: also, I've been working with a few others on a similar project, you guys are free to steal stuff we've been working on of course: https://github.com/Paril/q2pro/tree/rerelease-game it has most of the stuff you've been looking for here, I imagine MD5 would be the big one you want first though. |
@Paril thank you, for sure I will take some more ideas from it... My current plan to convert all models formats to single one. Currently code could convert MDL/dkm/FM to md2, so I need some code to convert md2 based formats to md5 or vice versa. I expect it will be exactly some md5 to md2 with improvements, just to keep render code mostly same. Also I am looking to code for convert 2023 network protocol to 39 when read demos. So code could support new demos and save old network codes. At least it's my current plans... What about heretic2, do we have in some future GPL game code? What do you predict? We have some crazy mix of yquake2 code and some non gpl licensed codes in https://github.com/0lvin/heretic2, but I have no idea when it will provide ability to pass first level. My idea is convert code to format of quake2 mod with minimal or mostly unnecessary/cosmetic hacks in engine itself |
I don't have any information about Heretic II - the acquisition just finished so maybe we'll see something come from that. |
I still hope for a reverse engineering of Oblivion's source code off that linux dump file |
Many years ago there were efforts to get the Heretic II source released under GPL2. Back then we were told that the code was lost. Of course no one knows if that was the truth. The other two games were the source code would be highly appreciated are Heavy Metal FAKK 2 including the Uber Tools and Anachronox. Mumbo Jumbo was mostly okay with releasing FAKK2 but chickened out at the last moment due to legal reasons. I don't know about any initiative to get Anachronox. |
If we get any of these at Nightdive I'll do what I can to get things open source, but that's about all I can do. |
Speaking of games that Nightdive has worked with - having Sin open sourced would be awesome :) Same for System Shock 2 (this was even planned back in 2018: https://twitter.com/pripyatbeast/status/1042823964542660608 - I wonder what happened to that plan). |
I have created new release, with automatic creation of win64 binaries. win32 could be also created only without ffmpeg based theora support, if some like compatibility with old mods. |
Has: * no hacks for replace md2 with md5 automatically(TODO), * no logic for merge anim and mesh content as required by loader(TODO), * automaticlly converted md5 to md2 like internal format. Part of #4 Based on: * http://tfc.duke.free.fr/coding/md5-specs-en.html * https://github.com/Shpoike/Quakespasm/blob/qsrebase/Quake/gl_model.c (Normals code) Also looked to: * https://github.com/Novum/vkQuake/blob/master/Quake/gl_model.c#L4181 * https://github.com/fte-team/fteqw/blob/master/engine/common/com_mesh.c * Paril/q2pro@1b42134
New release is created: https://github.com/yquake2/yquake2remaster/releases/tag/8.31RR4 It has support for get players models from pack files and md5 model format support. Md5 could be used as direct replacement of model, or as overwrite of initial model with placement in md5 subdirectory of initial md2 model. In first case need to edit md5mesh file and add list of skin files. In second case code will get list of skins from md2 file and add to mesh file, look to ded6b9c for exact code logic. @Bittermens could you please check that works for your case? |
the new models support works, it detected them automatically as the retextures, but the old AI is terrible |
We all know that Q2 uses some jank made by carmack that uses the internal Q2 software colormap and sound to make videos, and this is quite lostech these days, and really optimized it for pc's of that time until he removed all of it for better video and higher res texture support and bones animation for idtech 3.
So it is possible to make the old cinematic method as .wal textures and .md2 vertex animation models fires moved to "legacy" support so is it possible to add this quality of life upgrade for new stuff like new cutscenes, animation baked models and even new textures free of .wal as quake 1 and its source ports does? Quake 2 has a ton of potential but still tied to legacy coding, while Q1, Hexen 2 and Q3A moved from that and opened a new pandora box for it.
Many would love to mod for quake 2, the anniversary project proved that, but as of now the support is limited because of the legacy file formats, ever the SIN remaster if following the same philosophy.
it it possible to add this in future updates, i know the devs here even has some strong opinions even towards the old lazarus mod, but Q2 is in dire need of it as Q1 had and grew after it.
The text was updated successfully, but these errors were encountered: