GRAU

Strange. All screens. excluding the last 2 look primitive enough, but i respect your opinion. Btw - any other "doom-like" games in plans for sourceporting?

Tried RADIX and cant say thatr loked a lot, but the fact it uses the same patches for wall and floor textures is good - can delphidoom too just load textures in 32bit (with first time lauinch converting them into paleted and storing in the game cache in the png or any internal format) from the textures folder in zip, and then use them on the maps? I understant that it is offtop a bit, but i use png textures stored into the folder in zip file - for my zdoom projects. And zdoom project, and this is very usefull. I really want to move my projects to delphidoom but it needs some options first, especially - some udmf compatibility. As for radix - i really had an idea to create voxel models of aircrafts looking an the images, but i saw that there is a little enemies of the same type on the map and a few explosive barrels.. From this side MARS looks more interesting)) Anyway - thank you, Jval, for this sourceport!

Does it has any software analogs? Something with delphidoom renderer may be? Or does it uses too much "3D floors" and models? Actually i would like to create a few voxel pixelated cars and those extra long (high) street lights)))

Actualy the last version in development is stable on an old enough delphidoom 2.0.6 WIP and i am planning the release very soon. But anyway i like to see your gameplay and how it works on your system.

One more hanged guy

Are there any "full" instructions - how to compile lzdoom under win xp? I am not a coder but once over 10 years ago i had compiled GZDoom of some version for linux (xubuntu 11.04 maybe) succesfully. I didnt practice from that time because that netbook is lost and later i returned to xp where i had all i need untill previous year - when most of sourceports based on zdoom discontinued support for xp(((

I found the interesting function: "ChangeActorRoll" -that is from ACS, GZDoom. That is what it does: Then i thought - i have to request the improved version for delphidoom, but with support for software renderer. Could you make the function that can roll thecamera in the same flat? So i could immitate the alcohol or the leaning in Delphidoom? Would be nice to have both realizations - for Decorate (A_DCamRoll(horiz_pitch in degrees)) and a pascal script function DCameraRoll(Camera_tag,[pitch-parameter],[ roll parameter] and the same for player - PlayerID,[player pitch],[player_roll] As for software renderer - this can be done easy by just rotating the allready renderer 2D framebuffer around the center of the screen when roll is different from 0 Another Thing i think about too often last months is support for some kind of UDMF for delphidoom - i really allready could start transforming my horror project to delphidoom if i got those in DelphiDoom: - a) 3D floors, at least 4 3Dfloors per sector needed - b) Sloped Ceiling/floor for normal sectors (done) - c) Translucent 3Dfloors (at least 2 per sector) - d) 3D swimmable watter (with % alpha) - e) polyobject exciplit lines like in zdoom - f) floor and ceiling separate transformable texture X,Y offset, X,Y SCALE, rotations

which mods? then what is the reason to use LZDoom then? Its feature was the support for old fashioned OS and HW for me. Ok that means that i will need to for my own version from 3.87 or 3.82 that i liked best.

You got problems with ZDoom 2.8.1 on Windows 11? or the target os for you is mac? I tested zdoom on win 10 and everything worked fine. See no need in your version for windows users. May be somewhere on mac... I have no time for one more serious project. RDVOX and a horror game enough from me. I just was interested how really "retro" is your one. Now I see that not at all, just an empty sound. Dont worry about me, I still have have a great one named Delphidoom, an old fashioned but extra-optimized ZDoom and a more advanced version named LZDoom anyway. I want a ZDoom but with dynlights in software, implemented in QZDoom or LZdoom. LZdoom is OK on XP but in kind'a utilises sse2 or something like that - it runs great on Pentium 4 and Athlon 64 but crashes on start under Pentium 3 and earlier. Ofc there is a Delphidoom and it even has decoratem but i would prefer t see UDMF instead there - anyway i will need to use advanced Pascalscript for advanced actor logics. If there was an option to compile LZDoom without SSE - i would try that. Anyway o will need to make my own shanges once - i will need an engine for my game with imcompatibility with any interations of OpenGL or Vulkan, so there might be the only software with no chanfes to visibility in the darkness - only the way it does in zdoom now (to disable extra visibility of monsters in the darkness at any configs

Then how can you name your port RETRO zdoom? the real zdoom is far more retro ther your one! NAme in FRZdoom ther (FAKE RETRO Zdoom) - that will be the truth. I tested 0- even 32bit "Is not a win32 application" so no retro in your fork!

Iam the author of RDVOX, and i have the quake-style gibbing. Also there are some other mods having improved gibs. I want to say that the new sourceport needs some new featuresnew abilities or new optimizations for the allready existing ones, but the gibs are not Every decoratre modder can mae new gibs.I have a few far more interesting ideas for the software renderer zdoom based port. 1 - Keep the compatibility with non-sse CPUs like zdoom did, and ofc - keep compatibilities with win 2000 and XP - this is a nice advantafe for a software renderer sourceport. 2. - Using the base of ZDoom 2.7.1 try to implement dynamic lights from lzdoom - that was a really cool thing, the one of things i really like in softaware of Delphidoom and LZDoom 3. Try to fix those dynamic lights - they do not render on the sloped floors now. You also could enable the rendering of sloped 3d floors. As for gibs. As an author of a softwqre oriented voxel pack "RDVOX" i could create some gib graphics for you if it is still needed. I allso will support your port if you will keep compatibility with windows XP - this is primary requirement for me. The secondary one is upport for CPUS without SSE1 and sse2 - like pentium ll - no matter how slow it runs but please keep a support for 320 x 200 and 320 x 240 - this is really needed for me. 4 i also have a really interestibng idea - how can RZDoom become an unique port targeted on a sofrware renderer - if you could implement all 3 dimensional rotations for voxel models - try to start from the correct displayment of voxel projectiles - try to implement a,ligning the voxels front into the movement side in al 3 axis. Like models on GZDoom can. I hope this ill not be the one more "dead" copy of zdoom. GL for you, think about things i ask. Tested. Khm-khm. See no reason to keep compatibility specially with a sourceport that doesn't keep compatibility with hardware and software i like to play doom on. Try to represent compatibility with XP and may be i will have extra ideas for "your" software renderer.

Those are the great news! I'll find some time for that after releasing 0.42 for both sourceports, and then ill make first steps in marsvox

Yes they are. I allready use the rotation for gibs while they are "on air" and quake-style slow rotation for some items, and weapons dropped from enemies, so the weapon could be visible even between bodies(in delphidoom version. i could fix that for zdoom too i belive). But i do not rotate static weapons because this may unhide secrets somewhere.

Well, what can i say... Thank you sensei! I have fixed the code the way you adviced - and that criticall error didn't appear anymore. I want to believe - we have defeated this error))

Thanks, i'll check the "saveactordef" command!

Hmm... Strange enough. There are not too much large voxels ib my pack. It has not to take a lot of time, i belive. What other operations are processor heavy? Ofc - you will never get slowdown on any i7, i belive, even of 1st generation. But the startup of delphidoom is now over 3 times longer then the startup of zdoom or lzdoom on single-core Pentium/Celron M Processors. It takes each time over 40-50 seconds, with rddvox only. However, i could check - how long does the startup take without any additional wads! May be RDDVOX doesnt slowdown it a lot. Yes, they are, but before i renamed them to rdw/gibs they were gore/gibs but i still had no sound of meat explosion ingame. But i will check the sound defibition once more, thanks. Sounds Good! I'll check this func. Interesting - i had no problems spawning shotguy heads nor Chainguy ones. Both spawned well after explosion. But this error appears in random moments when damaging chainguys.. But this is not 100% info, just my feelings. Thank you for advanced feedback, i have to go patch up my issuepack now)))

I got heavy issues in porting gib system from rdvox 0.41 to delphidoom. It rins. it works, it is fun a bit but it is far from perfect and i do not know what to do with those: 1) Why do sounds defined in sndinfo not work? What action do i need to use instead of A_PlaySound or A_PlaySoundEx? 2) Where can i find the original code of the actors in delphidoom? i looked at SWD file - there are only water and lava splashes there((( 3) What does this error means? It sometimes appears on map03 (or any other map where chainguys are, i feel, but it always appears on demomap rdvxtest, when entering a subsection with zombiemans (to the right from spawn square room, cross the bridge over lava, - you allready see it, near the green torch). I add the files. RDDVOX-0.41.7.zip RDVXTEST.zip I want to finish it till 31dec2021, BUT! some kind of satanaclaus does nt want this thing happen!

I have a question for delphidoom launch optimization. How much sprite angles does delphidoom generate for each non-existing sprite frame in voxeldef? 1? 8? or even 16? I see that delphidoom does something over a minute when launching with current rddvox on my notebook. if it creates tonns of sprites - i would like to have an option for that - create a 2x2 dummy sprite for each voxel frame, create only 1 true frame (like med1a0) but without rotations, and the last - create 8 angle sprites. Actually 8 rotation sprites are really not needed for voxeled virtual frames - if someone launches a mod based on voxels - he may be want to see voxels, and he does not need all those sprite generations on game launch. But if there is a person who preferes sprites created from voxels - then he has an option for that.

That is why i hadn't found it)))) I am thinking about upgrading the resources of the mars - redrawing some weapons into more rusty, brutal and realistic... But i dont sure - does someone else like this idea? What about the a community mars (hud) respriting project? all items could be recreated in voxel, i can take care on this but i have a bit different vision of some wunderwaffes from this game...

I am working on porting new gibs from RDVOX (ZDoom version) 0.41 to RDDVOX (DelphiDoom ver.) 0.41 or 0.42 may be - because 0.41 for zdom was released with much simplier gib graphics, and the delphidoom version is going to have much better gib voxels on release, here are imp head voxel variations, for example: One of them is for the "on air" head visualization, and others will appear on the ground instead! Also other gibable monsters (all zombies) will get some new gib variations and improvements for allready-finished in 0.41 graphics. So i belive 0 the Delphidoom Voxel Pack version will have NOT the 0.41 version on release but something like 0.41-D version or even 0.42 instantly. Also i have found that delphidoom has coloured blood in it's basic graphics, so ill look - what can i do to improve non-red blood. May be i will add some small blood pools staying on the ground after large blood splats. The other question is comparing all those changes with ZDoom version - i want to have the same features ang graphic sets in both versions, but looks like some things are still gong to stay different...

Such a strange combination! What resolution actually has the monitor display matrix? does it really has 1200 dots in height or this is a virtual resoluton that is actually rendered on 1080p height? can you print the model of your monitor? just the hardware interest))) Actually - is Your sourceport name is "Mars 3D"? I am talking just about the name of the port, so i could name my voxelpack optimally, matching some of first letters from port name. Didn't you think about the "DelphiMars" name?

Oh, you a re great, so many soft you have created for doom and doom-type games, now i will start my experience in... "RM3DVOX"(Renaissance Mars3D VOX), may be?? or "RDMVOX", "RMDVOX" (Rennaisance Delphy Mars VOX)? are there any other sourceports for this game?

Of course! Especially if someone other than me needs it. But of course I can't do it as fast as RDVOX. I also have some interest in creating my SOME voxels for NBlood, but still MARS looks less well-known to me, and needs my voxels far more. Who if not me?))) Another reason - i have created a thread about Your sourceport and MARS3D on i.iddqd.ru - it is Russian Doomer forum, and i belive some of them will like your port, this game,a nd my voxel addons too!

Any voxel support for this Mars? Any dynlights? Looks like i want to try this game.. But you know me - i have to make some resources first)))