|
Post by 3t0 on Jul 23, 2022 16:44:30 GMT -5
I'm not sure about that. I don't have all that much experience with Unity, but I do have enough to doubt this claim. I think you shouldn't undersell the Prodeus editor, not unless you have specific insight into it that I don't. It's doing things differently from any other map editor I've used, and I've used a few. Sure, it's going to benefit from the features of the underlying engine, but that doesn't just immediately launch you from a blank slate to an eminently usable 3D modeling tool. Have you actually seen or used the Prodeus editor? Otherwise I would be happier not to denigrate what appears clearly to me to have taken a whole lot of work on the part of a couple of guys who may very well have been working out of their bedrooms. (Even if I will point out that I think they missed the mark on the actual gameplay...) As far as I know Unity projects are some packed format and are decompilable, so if you have access to actual Prodeus Editor, with bit of spelunking and fooling around you should be able to decompile the editor source and look at the code. I bet it will be "modern code". Pretty please understand me, I am not denigrating anything - Prodeus and it's editor is a fine work. Lot of love went into it. It's job done well. But exactly because Unity is a substrate, exactly that amount of work could have gone into it. They could have spent more time to polish it for you, because they didn't have to fight the basics. You kinda understand what I am trying to tell you, but you kinda want not to. Why I feel I am allowed to talk about it: you see, I have engine spelunking disease - that is my obsession. I tried many of them cube 1, cube 2: sauerbraten, doom , build, quakes. Every time I get further, I find some annoyance in the engine that I am studying, that make me completely reconsider it and often abandon it. As you can guess, I currently have k8v phase (but very light only) and I also spelunk with quakespasmspiked and fteqw again. My drive is littered with game engine sources and my forks, that went nowhere. I want you to understand what new kids might want call "legacy code", that these old engines stem from. So, at time I did mess a lot with build (duke, shadow, warrior blood, ion fury). I found Ken's raw BUILD source and jfDuke, got both of them to compile. Sidenote: because of Ken' stupid license, BUILDLIC.TXT - BUILD engine is essentially eternally fucked - but existence of Ion Fury proves the BUILD community is also essentially mad. JfDuke was progressing beautifully in all the auxiliary areas, but during that time there was not much development on the renderer, i.e. taking it to OpenGL and bringing it to BUILD - do you know why? Because Ken is genius idiot savant (sorry Ken). It's completely different programming style, one that current generations of programmers with minds fucked with OOP would never come up with. Don't get me wrong, it's valid C, but variable naming and shit - unless you are a math whiz kid, recognize some math theorem used (by part of equation) and are just regular Joe, you have no fucking clue to discover what's going on - it is completely opaque to you. So basically nobody besides Ken understood the damn thing's code (or was at intersection of coding level and math level needed to read it and was interested in BUILD at the same time), and thus nobody could write BUILDs OpenGL renderer. At some point Ken got pissed that Dooms have had OpenGL some years now (I just assume) and went and wrote polymost.c which is BUILDs OpenGL renderer used to this day. Now you would guess this Polymost would be some "sane"/"hardware realities conservative" renderer akin to what Quake, or what modern game engines, like Unity, do - but no! This is Ken we are talking about. Maybe you know maybe not, there are two things how to drive the HW card: let's call them immediate and retained. In immediate mode you send information from CPU to card, piece by piece, and it draws it into the scene. This is how HW acceleration started everywhere from SGI workstations to 3dfx cards on PCs and chips in consoles. But this IS NOT HOW HW acceleration ended - we now live in fully retained world! This is also reason why GZDoom and k8v have framerate problems, as pointed out by ketmar. In my opnion k8v is better off in this regard. In this other, retained mode you send all the shit to graphics card beforehand - and tell it what to do with it. This is now 90% of your engine, telling the card how to draw your game and sending it all the shit, figuring how to do it. Once you get this stuff uploaded to the card, right way(!, I add), card itself draws the shit, draws the game, it does not give a fuck about you and what you do, it just wants to steamroll alone forward as far as possible. And, all this works, if all the information you send to the card is static, i.e. doesn't change in time and space. Yes in modern games actors/enemies "don't move" (their models) - yeah outrageous claim, but true - in modern games all actors you see on screen are infinitely standing still and T-posing. It is the card itself that is bending and ragdolling them like puppets, in fact CPU doesn't even know really - think about it for a second. It's very strange world, where engines don't engine and actors and levels don't move and change - yet cards bend them in their hardware to look moving. And by 2000 it was obvious, that this will be the world from now on. Now look at Ken ... he did exactly the opposite, he wrote this fucking weird polymost thing, which works in immediate mode, where sector walls are converted into 2D parallelograms (pgrams from now on) that "project" onto screen view-plane (I hope you can imagine it). This pgrams are split JIT at the moment of frame drawing, so they have to be sent to card again and again each frame, pgram by pgram. But all 4 on-screen vertices of these projected pgrams have also Z-attached (as in screen-depth) so they can mesh, by virtue of Z-buffer, with "traditionally" rendered 3D-models. This rendering tech is awesome/magic/weird and completely fucked up. First implication: as these pgrams are transitional things, generated on the fly, they cannot be cached in card's hw, thus this polymost renderer is completely CPU bound. Even current doom ports, I hope, have better tech. Second thing: because at some camera orientations, wall projections stop being pgrams, this magic thing explodes at very upward and downward looking angles. So even in 2005+ you cannot look straight down or up in fucking OpenGL BUILD rendered games, because Ken is crazy. I also believe, that if you nagged him enough, he would come up with some crazy solution using n-dimensional p-spaces to make look up and down work . If you go to polymost source, disable up/down yaw limiters (in rads I think? no degrees for you my friend), you will see how the pgrams ass-plode, when you look straight/up down. Weird as shit, plus it goes completely against what modern cards want to do. Now you ask me, what is then a benefit and why was it done that way? Well BUILD games are insanely dynamic. In BUILD anything can move at any time - any wall corner, any sector floor/ceiling height, any slope. This polymost does not map to modern HW in the slightest, but maps to what BUILD is completely. Polymost allows BUILD game to preserve it's "dymaic-ness" that is unlike any other - not that level designers move corners in build around much - and have it use OpenGL in the process. Very weird thing. Now go, read the intro if you wish here github.com/retrofw/eduke32/blob/master/src/build/src/polymost.c#L1= and then tell me please, what the fuck is happening here: github.com/retrofw/eduke32/blob/master/src/build/src/polymost.c#L2209= ? Ken's code is always like that: gg, zz, ax, by, cc, yhacks[], zmods[]. Hand optimized bitshifts, in array indice calculations and crazy amount of other "old"/"clever" C bittwiddling tricks. If show this to 9 from 10 javacsript hipsters today, they will blank stare, deer in headlights, brain turned to mush. If ten of us would look at it for week, we would eventually decode it. I hope. You actually need another genius to untangle these power spaghetti : fabiensanglard.net/duke3d/build_engine_internals.php and write report on how to read them a decade later. Better read conclusion too fabiensanglard.net/duke3d/code_legacy.php : But that is not true: original Doom itself is similar level of power-sphagetti and that we got from that to working modern OpenGL sourceports is a miracle. So the issue is not just "graphics programming", the issue is understanding the past, the present and the future - wow Dune reference just here . Your "modern" `level.GetActor("Player").walkTo(target, ACTOR_WALK_SLOWLY);` does not translate to these old beast of engines. Unity is that. Doom is more like polymost, even if C++ beautified, VavoomC and everything. Thus each and every change becomes complex yak shaving exercise, testing your software archeology skills, math skills, C skills, C++ skills etc. I hope you understand better now, what I am trying to make you comprehend. Once you get that, you can preach this gospel to others. There is a "Doom-way" and "k8v-way" derived from that. This way understands the limit and bound imposed.
|
|
|
Post by 3t0 on Jul 23, 2022 17:17:44 GMT -5
'cmon, you don't even need it, because each linedef already has precalculated direction and normal vectors for you! Sorry ketmar that was just for sake of argument, I know how it is. Younger people imagine tighter OOPish separation in doom engines - or I don't know how to call it - that is simply not there. And they are too lazy to read the code too. Cool, thank you for the response. I am interested in making the most I can out of k8vavoom, but 3D floors are nice to have, and I feel that sector lighting behaving in a standard way is a pretty important part of that feature. That is why it's amazing that you are doing what you are doing - you now stress tested the codepaths for this. Just from correspondence with ketmar I know he is more proponent of 3D-floors VS portals. Janis seemed also to prefer 3D floors on original vavoom page (now defunct). It also means more Quake-y, vavoom always was most Quakyfied engine. The more this feature is stress-tesed the better k8v will get at it. I also tried this `PipeFactory.wad` from forum.zdoom.org/viewtopic.php?p=1210994#p1210994 and it seems it works decently but there is weird shadow under the pipe halves as well. Portals are very BUILDy and while probably good for mappers, they are not such a win compared to complexity they bring. The height control using texture name seems quite weird, especially since UDMF there could be property to just to move them to desired height directly. Second thing: isn't it already possible in k8v with 3D midtex? As you can guess, I didn't put much time into my mapping skills, since I am messing with UDB in linux and it is slightly frustrating.
|
|
|
Post by 3t0 on Jul 23, 2022 17:26:49 GMT -5
But k8vavoom doesn't even have build instructions, that I could find! That makes it very difficult to even think about contributing, about e.g. investigating those sector lighting bugs my own self instead of just complaining about them on a forum. Well now comes the dreaded question: are you on windows? Because k8v has pretty standard build system: cmake. Seems it's cmake is pretty current too, I never had a problem - looking at you DoomLegacy (I never succeeded at compiling that shit - @gibbon wouldn't you be willing to grant your infinite experience and make that peace of shit compile on modern systems - ie not debian?) If you are on Linux meapineapple, I can share you my layout, but if not, it's useless to you.
|
|
|
Post by meapineapple on Jul 23, 2022 17:52:43 GMT -5
Ha, that would take a while to untangle. But I'm surprised it hasn't been done yet. The function as a whole is quite obfuscated in the details, but the big picture seems clear enough. And it sure looks like the specific part that you linked me to might well be related to the exploding at upward and downward angles, given that it's apparently a special case in converting world coordinates to screen coordinates when the camera tilt angle is 0. I'm guessing you knew at least that much already. It would certainly take some doing to puzzle out the precise effect, but since I don't personally have much interest in the Build engine I am very happy to leave that to others. Thankfully, the challenges with hardware-accelerated Doom rendering seem a little more manageable, since it's only the floors and ceilings that can move, and then only in specially tagged and statically known sectors. Well now comes the dreaded question: are you on windows? If you are on Linux meapineapple, I can share you my layout, but if not, it's useless to you. I am, in fact, on both.
|
|
|
Post by 3t0 on Jul 23, 2022 18:17:07 GMT -5
Okay then on linux all you need is cmake and your distro dev packages. cmake builds software out of tree that means compilation artifacts are not placed in the same dirtree as sources. In fact cmake is build generator, and can generate build directives for multiple building backends - usually you use traditional gnu make. If you never did cmake build the process is like this: - make some empty builddir somehwere
- `cd builddir`
- in builddir `cmake pathtosourcedir`
- if everything went well, you will get Makefile generated without error, in the builddir
- in builddir `make` will compile the software
- in builddir `make install` will depose it somehwere runnable - by default system wide install
I prefer to have more flexible struturue, so my setup is more complicated, I have a topdir k8vavoom and there are: - <dir>k8vavoom.src - here is the unpacked fossil source
- <dir>k8vavoom.sripts - here are my script lines, that I am lazy to remeber
- <dir>k8vavoom.notes - various notes I collect through forums and such
- <dir>k8vavoom.build - this is my cmake build dir where k8v is built in
- <dir>k8vavoom.run - this is dir where I install my k8v instead of system locations
- <file>k8vavoom.fossil - needs no explanation
Some software and first builds of k8v could be run in place (I think) from builddir, but later it become too cumbersome - my memory is hazy - I just install it unto k8vavoom.run. That way I can zap current k8v install and start from clean slate quickly. Same with k8vavoom.build, I often regen it from scratch. This snippets inits my builddir and ensures k8v is installable into k8vavoom.run dir: : pwd .../k8vavoom/k8vavoom.scripts : cat cmake:init-buildidr.sh #!/bin/sh
test "$(basename "$(realpath .)")" = "k8vavoom" && cd "k8vavoom.build"
test "$(basename "$(realpath .)")" = "k8vavoom.build" || exit 110
exec cmake \ -DCMAKE_INSTALL_PREFIX="$(realpath ../k8vavoom.run)" \ -DENABLE_MD2FIXER=ON \ ../k8vavoom.src
This snippet builds k8v using 4 processors: : pwd .../k8vavoom/k8vavoom.scripts : cat make:build.sh #!/bin/sh
test "$(basename "$(realpath .)")" = "k8vavoom" && cd "k8vavoom.build"
test "$(basename "$(realpath .)")" = "k8vavoom.build" || exit 110
exec make \ -j 4
Then just `cd k8vavoom.run; bin/k8vavoom`. It's just a wrapper script. Don't forget this won't work well in VM I guess, unless you have proper OpenGL there, naturally. I am on Linux everywhere, so it doesn't matter to me. MSX build is currently out of my scope, as I don't have need for windows, but one day I might get it working too. This should get you going.
|
|
|
Post by 3t0 on Jul 23, 2022 18:53:40 GMT -5
I'm guessing you knew at least that much already. It would certainly take some doing to puzzle out the precise effect, but since I don't personally have much interest in the Build engine I am very happy to leave that to others. Thankfully, the challenges with hardware-accelerated Doom rendering seem a little more manageable, since it's only the floors and ceilings that can move, and then only in specially tagged and statically known sectors. You kinda passed my test - I personally am not that good in math, so it took me some time to figure, and it was almost decade ago - phew time flies. Still polymost is pretty readable, if you are feeling adventurous read software renderer part, analysed by fabien as well - that one is even uglier - that is where people gave up. It's not waste of time entirely, either. At one point I would really like to try to make my own indie game LOL, and I would like to use something like k8v, fteqw or qss, something unecumbered by parasitic capitalist bullshit (unity/unreal is free LOL), thus for me GPL or BSD is quite important facet. Unfrotunately BUILDLIC.TXT is either free for noncommercial or licensed for profit, so that killed BUILD for me. More over, modern Doom 3D floors always look much better than BUILD's fake portals, albeit Ion Fury really has best implementation of them. What I like about Doom is the speed of map creation and sprite actors, and overall simplicity. What I hate is that exteriors still look shitty as fuck. In my experiments triangle sector + heighted vertex landscapes look pretty good though, at least in my opinion, so last controversial thing I would really love to have is "cave/external/organic walls". This is where my experimentation got me to. I have not yet pitched my idea to ketmar , maybe he would be open to it. It's really hard to guess what he considers good for k8v and what not. But at least we can always ask, for now. Creator wise, I think it would be easiest to "just" have at least Quake1 BSP2 loader really, even as just "brushmodel" akin to MD2/MD3. I think Hyper3DGE tried to go that way, but it imploded somehow into itself - I don't follow doom drama too much, but I heard there was some project implosion. The problem with BSP is collision detection and the whole integration which belongs to the same realm of implementation difficulty as other proposals eternally circulating doom community. There are few other things I would really love to have, which sound completely crazy to most doomers (and it's not such exhaustive list as one would think), but the fact that I cannot find much time to do even mapping, and each of them would require some editing support, makes it highly unrealistic to push for them . So I am just happy camping here with all of you. the whole mirror/reflection code is very broken for now. Bummer, I tried to emulate body of water with reflection only to learn it doesn't work. One can wait then, maybe one day I guess. ketmar so second dastardly question: is shadow mapping and overall k8v lightning model supposed to work on model triangles too? I am always blown away by k8v sprite shadows in shadowmap mode - but can I project shadows onto MD2/3?
|
|
|
Post by 3t0 on Jul 23, 2022 19:47:46 GMT -5
Documentation isn't an all-or-nothing thing! It doesn't have to be a mammoth years-long task. Every little bit helps to lower the barrier for potential new contributors. Well there is `docs/k8vavoom.txt` but we were so nice to not RTFM you, but if you are interested, you should probably read it by now. I reread it after you talked about build system - haven't seen it some time - and the complete build directions are indeed there. But I also think k8v is reaching a point where it will need for some better docs. Let's call them pretty-docs/book. Now the question is how to go around this. This is complex question though. What follows is my stream of consciousness about the issue. In my experience, I would suggest using something akin to mdBook which Void Linux uses, but actual upstream mdBook is imho shit. Hugo seems to be a shit too - both partly because they pull-in lot of surveillance capitalist bullshit. Both things are external static generators, so they could generate book directly from the source. This pretty-docs book would be part of k8v repo and thus it would be protected from spamming - only devs and determined individuals would care to commit edits - and all edits would go through ketmar. k8v doesn't even have a web domain - should the ketmar's machine go under, there would be copy of the book in every cloned repo - so this would provide quite a redundancy - the book would be also easy to publish to the web: just let webserver pass-through to it on k8v site. As vavoom site went under seems these people: Rachael (Eruanna) Alexanderson, Nigel (Enjay) Rowand, salvaged the site, but the current site is not the original version. "Book in repo" would prevent from formatting and shit getting lost because of similar salvaging in the future etc. Now ketmar has wiki in fossil, but I think that is not a good spot to store the pretty-docs book. The book could be thought of as FreeBSD Handbook or DoomLegacy manual. It should be it's own artifact. There, people interested, should transfer all the line specials, ACS, UDMF properties and everything from on the web scattered vavoom resources and update it to k8v status. Zdoom wiki-like sector tutorials showcasing k8v features with images could be stored there and so on. Second thing ketmar often asks for are test maps, so maybe there should be a `maps` dir added to the repo? `maps/test` could contain test maps and `maps/examples` could contain technology examples for each feature? I don't know this is complex topic - but I hate the modern way where you need to fuck around with some remote website to read docs - having local docs always at hand would feel the best IMHO.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 24, 2022 1:29:40 GMT -5
But k8vavoom doesn't even have build instructions, that I could find! That makes it very difficult to even think about contributing, about e.g. investigating those sector lighting bugs my own self instead of just complaining about them on a forum. Well now comes the dreaded question: are you on windows? Because k8v has pretty standard build system: cmake. Seems it's cmake is pretty current too, I never had a problem - looking at you DoomLegacy (I never succeeded at compiling that shit - @gibbon wouldn't you be willing to grant your infinite experience and make that peace of shit compile on modern systems - ie not debian?) If you are on Linux meapineapple, I can share you my layout, but if not, it's useless to you. I already did a while ago. I made a build for plain old mingw32 systems as well as on my raspberry pi and x64 Linux machine. You don’t need any build instructions, it’s all very simple. Make sure all dependencies are satisfied, use cmake, then make. If you meant Doom Legacy, yeah I also did that one. Wesley has created a pretty shitty build system that harks back to the fucking 90’s but it does work when you have set up the thing.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 24, 2022 2:06:32 GMT -5
I don't want to imagine how "nastily"/"cleverly" PBR is shoehorned into GZDoom pipeline. It's hardly at the top of my feature wishlist but, I mean, PBR in Doom is kind of cool. Writing anything in these systems is just mashing APIs together to get behaviour you want. Yeah I can imagine you can have working Prodeus editor pretty quickly. I'm not sure about that. I don't have all that much experience with Unity, but I do have enough to doubt this claim. I think you shouldn't undersell the Prodeus editor, not unless you have specific insight into it that I don't. It's doing things differently from any other map editor I've used, and I've used a few. Sure, it's going to benefit from the features of the underlying engine, but that doesn't just immediately launch you from a blank slate to an eminently usable 3D modeling tool. Have you actually seen or used the Prodeus editor? Otherwise I would be happier not to denigrate what appears clearly to me to have taken a whole lot of work on the part of a couple of guys who may very well have been working out of their bedrooms. (Even if I will point out that I think they missed the mark on the actual gameplay...) Then some Unreal spoiled kid comes and bawls: "bwaaah gzdoom is unoptimized", "bwaaah k8v cannot do this, cannot do that". "Yes, you cannot do that.", "Bwud bwud wdubb Unreal can, smirk...". Really? Then patches welcome, or fuck off to Unreal kid. I think this is partly a problem of documentation. I'm hardly a graphics programmer, but there are certainly ways that I could usefully contribute to k8vavoom, if only I knew my way around it. Engines like Unity and Unreal have heaps and heaps of documentation explaining how to interact with them. Doom ports, k8vavoom included, tend to have very little. So, yes, there will always be entitled people demanding that someone else do the work for them. But even fairly competent people like me, who often contribute to open source projects, can hit a wall if "patches welcome" is not accompanied by "and here's the documentation". When I encounter bugs in the open source software I use, more often than not I fix them myself. My code is in projects ranging from eslint to openmw. But k8vavoom doesn't even have build instructions, that I could find! That makes it very difficult to even think about contributing, about e.g. investigating those sector lighting bugs my own self instead of just complaining about them on a forum. I get it, I get that demanding documentation isn't any better than demanding features, it still takes work. That's not my intention. I'm just trying to point out why the situation here might not be ideal. They have heaps and heaps of documentation because they have a team of analysts writing the documentation. That and since it is paid for, well it is kind of expected. IMO programmers should have the intelligence to learn things without documentation. When I was a kid, I was writing 6502 assembler programs with basically zero documentation except that which came with my C64. I really worry about the grads coming out having done a bit of Java in CS classes and basically not knowing anything. Assembly programming should at least be mandatory for the first 3 years.
|
|
|
Post by ketmar on Jul 24, 2022 4:05:29 GMT -5
For example, how would someone be sure that it was bog-standard cmake without combing through all your build-related files to see what's going on by seeing "CMakeLists.txt" in the project root directory. ;-) any *nix user with minimal expirience in building software from sources will immediately recognise that file. also, the official site has the document about building on windows, written by Steinkrauz. and by the way: README (i absolutely believe that every user always reads READMEs, in full! ;-) says: "For all the other flavours of GNU/Linux you have to compile k8vavoom from the sources. … Please, refer to "docs/k8vavoom.txt" for more info.". and docs/k8vavoom.txt contains sections about dependencies, and even step-by-step building instructions. ;-) P.S.: still, that information can be better presented, and should be easier to spot, there's nothing to argue about here.
|
|
|
Post by ketmar on Jul 24, 2022 4:22:22 GMT -5
Some software and first builds of k8v could be run in place (I think) from builddir please, NEVER EVER do that. actually, the engine should detect it, complain and exit. ;-) my build script installs everything in "/opt/vavoom", for example (historical path from the days when k8vavoom didn't even had it's own name ;-). and building with MXE is as easy as installing MXE (with all required k8vavoom dependencies), and doing the very same cmake, only this time using the cmake from MXE package. It's really hard to guess what he considers good for k8v and what not. But at least we can always ask, for now. anything that can be implemented without much pain within the current engine architecture, and won't require heavy maintenance in the future is "pass". except if it conflicts with some my future plans… which, i guess, returns us back to point zero. ;-) ketmar so second dastardly question: is shadow mapping and overall k8v lightning model supposed to work on model triangles too? I am always blown away by k8v sprite shadows in shadowmap mode - but can I project shadows onto MD2/3? sure! they both cast, and receive shadows. there is a small problem, tho: models are prone to "moire", because i couldn't do the same trick as with map geometry to fix it. i don't remember right now what and why, but shadows casted *onto* models often have moire pattern. as i'm not a big fan of using models as level decorations, and fixing that will require a lot of work, and will slow down the shader considerably, i simply left it as it is now. ;-)
|
|
|
Post by meapineapple on Jul 24, 2022 4:43:27 GMT -5
and by the way: README (i absolutely believe that every user always reads READMEs, in full! ;-) says: "For all the other flavours of GNU/Linux you have to compile k8vavoom from the sources. … Please, refer to "docs/k8vavoom.txt" for more info.". and docs/k8vavoom.txt contains sections about dependencies, and even step-by-step building instructions. ;-) Whoops, that's my bad then. But that's also why the "clearly labeled" part is so important. I was looking for anything that said "build" or "building" or "how to build" or "build instructions", and ended up flying right past the parts that said "installation"... Though I'm not quite sure how "winbuild.md" got past me. I'm new to this code! There's a lot here, and I don't know what I'm looking for, and I never claimed to be smart. If there were e.g. a BUILDING file alongside the README and LICENSE, that's the sort of thing that would have been impossible to miss, even for my crappy eyes.
|
|
|
Post by 3t0 on Jul 24, 2022 6:00:51 GMT -5
@gibbon yeah my request pertained to DoomLegacy solely, not k8v. I was trying to build their official release, do you have your own fork, or have you contributed to upstream? If you meant Doom Legacy, yeah I also did that one. Wesley has created a pretty shitty build system that harks back to the fucking 90’s but it does work when you have set up the thing. I am currently dying after having TNL (some Torque Networking Library) compile. It was fucking weird experience, but in the end I commented offending macrocode for ASM detection and that make it compile & link, but now the damn build dies because it cannot find LEMON parser, I guess??? If this is a sqlite part I think it is, and this tool doesn't seem to be packaged separately, so I wonder why it hasn't been included into DoomLegacy code repo directly - one has to hunt for it on the net. Also why Legacy guys don't include TNL into the sourcetree ? It's such obscure networking library. Kinda off-topic since this is k8v thread, but I asked anyway.
|
|
|
Post by 3t0 on Jul 24, 2022 6:03:58 GMT -5
please, NEVER EVER do that. actually, the engine should detect it, complain and exit. ;-) my build script installs everything in "/opt/vavoom", for example (historical path from the days when k8vavoom didn't even had it's own name ;-). I stopped doing that and came up with structure described the moment k8v in-place stopped working for me. and building with MXE is as easy as installing MXE (with all required k8vavoom dependencies), and doing the very same cmake, only this time using the cmake from MXE package. Yes I have to try this - too lazy - this supposedly should allow me to make windows binaries on linux right? That is most awesome in itself. I hate windows VMs not having any. anything that can be implemented without much pain within the current engine architecture, and won't require heavy maintenance in the future is "pass". except if it conflicts with some my future plans… which, i guess, returns us back to point zero. ;-) I have to compose my thoughts and shoot for presentation at some point then .
|
|
|
Post by ketmar on Jul 24, 2022 7:43:53 GMT -5
If there were e.g. a BUILDING file alongside the README and LICENSE, that's the sort of thing that would have been impossible to miss, even for my crappy eyes. yeah, good idea. i'll prolly write it soon, thank you! and building with MXE is as easy as installing MXE (with all required k8vavoom dependencies), and doing the very same cmake, only this time using the cmake from MXE package. Yes I have to try this - too lazy - this supposedly should allow me to make windows binaries on linux right? That is most awesome in itself. I hate windows VMs not having any. yes. and by default it should create static builds, so no .dlls lying around.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 26, 2022 7:35:42 GMT -5
I have to start using MXE too. I just worry too much about not being able to test it on 'a real OS'. One thing that would drive me nuts is people saying "oh it doesn't work on so and so" and not being able to try it out.. that's the only reason I keep Windows around really.. Even though GNU/Linux is the 'real home' of Doom
|
|
|
Post by camper on Jul 30, 2022 16:53:05 GMT -5
Nash made Standalone Game Template (https://forum.zdoom.org/viewtopic.php?f=37&t=70232#p1169284). Is it possible to remake it, remove the zscript and add the necessary settings so that it can be run in k8? Unfortunately, I don't know how, but I need this to learn. Doom is too big so that I can cover it all, I want to have a small starter pack for experiments.
|
|
|
Post by 3t0 on Jul 31, 2022 15:21:24 GMT -5
camper Seems there is rudimentary support for gameinfo so it could/should work. : ag GAMEINFO progs/common/linespec/linespec/LineSpecialGameInfo.vc ... ... source/filesys/fsmoddetect.cpp 409: int fidx = hlp.findLump("GAMEINFO"); ...
I would also spelunk around basev (baseavvoom) data directories a bit. In fact if you successfully manage to make working standalone gamedir/pk3/iwad, it would be great to share your findings maybe even a sample here.
|
|
|
Post by camper on Aug 1, 2022 3:31:20 GMT -5
|
|
|
Post by camper on Aug 7, 2022 12:27:23 GMT -5
Is it right that k8vavoom already has an RPG component similar to strife? Is there any plan to expand this? For example, add a weight parameter for items and weapons in the inventory to limit their carry amount through the character's carrying capacity?
|
|
|
Post by ketmar on Aug 7, 2022 12:39:12 GMT -5
i don't have such plans. it is possible to implement this with VavoomC as a mod, but i personally have no intention to create such code.
|
|
|
Post by 3t0 on Aug 7, 2022 19:48:08 GMT -5
So, just verify - it is possible to have own standalone game/iwad with k8v?
|
|
|
Post by ketmar on Aug 7, 2022 19:53:56 GMT -5
of course. the whole playsim (including physics) is written with VavoomC, there is no problem to create any other playsim instead. the whole user UI is in VavoomC too, btw. it is even possible to create a 2D game, either by doing it in the UI layer, or by rendering on top of the 3D scene.
|
|
|
Post by camper on Aug 8, 2022 3:28:16 GMT -5
So, just verify - it is possible to have own standalone game/iwad with k8v? Of course! I gave a link to a video with an example in the post (Aug 1, 2022 at 11:31am). There are no iwads in the examples, only ipk3 from Nash was used. upd: I'm wrong, I forgot to delete the wad files from the folder. Does not start in K8vavoom. Runs in GZDoom: open.tube/videos/watch/4a4402a9-54d8-4f86-8726-180620b2af10
|
|
|
Post by camper on Aug 12, 2022 9:57:17 GMT -5
To the previous post. I managed to run this ipk3 if the in iwads folder is bootstrap wad (11 kB). For example, from the old version of Freedoom 0.5: github.com/freedoom/freedoom/releases/tag/v0.5In old k8 builds, it was possible to launch some maps with this bootstrap wad (latest version when it the bootstrap wad worked was 560511), without resources doom/doom2 (only those contained in the maps and mods themselves were loaded). But then it stopped working, and with ipk3 it works again (relevant for 570509).
|
|