Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

GRAU

Members
  • Content count

    79
  • Joined

  • Last visited

Everything posted by GRAU

  1. Hi all! I want to present my, and another my's creation named RDVOX. This voxel pack is in progress, it actualy contains not only voxels, but: - a couple of new sprites, and code oriented to create fireball and fire effects - light definitions to use with advanced software renderers (8bit priorm but 32bit and GL are also working nice) - a new palete, oriented to help the engine to render dynamic ights and cool sprite effects in 8bit software. If somewhere it damages original graphics - please make a screenshot for me, ill fix It does NOT changes gameplay or any parameters of weapons. If i will do such addons - they will be separated from maun pack. I orient it ti use with 8bit renderer, all the effects are tested there, 32bit and GL are not prior, so if they somewhere look strange - you have to show me a screenshot, ill try to fix, but only if it will not damake the look in 8bit. All voxels, sprites and code here are made by ME and onlt by Me (ConradRDW, GRAU are both my personalities :D ) Some textures added to palete pack to fix their look under this palete. They are taken from original game now but will be replaced by their clones soon. You may play with it as much as you want. You may distribute it for free as much as you want, but specify my nickname or my site then. If someone want to take some of my resources to his own project - he have to contact me. All rights reserved ;) You may always find a last stable version on my web page: RDW Studios Or find a development/tester release here: Q/L/G/ZDoom version - RDVOX-0.38a.zip Delphidoom version - RDDVOX-0.38a.zip As for ZDoom-based sourceports - you may use any you like, starting from ZDoom 2.8.1. Actually stable release of delphidoom has no support for this pack and dynlights too. But you may use WIP version: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20191222.zip/download - Thanks jval. You may also look at his topic in future to find latest updates of this sourceport: Demomap (map01) with all things i have created yet - RDVXTEST.zip But some monster attacks are not demonstrated there - better try some cool vanilla or boom wads instead :) Known problems: - Some of new sprites look weird in delphidoom version. This is because of specific translucency logic and will be fixed soon. - A few original game sprites or textures may look weird - this may be caused by new palete - please repord such situations here, specify your sourceport please, it can help in fixing the problem too And now a few screenshots. I will use QZDoom q2.00 for that - i like delphidoom but it's dynlights have been just implemented a few days ago and look weak now:
  2. Hello. I have got a request. Implement please a smart palete-replacement algorithm into delphidoom. For example. I load RDVOX to play it with doom 2. And the normal blue indexes are somehow shifted in RDVOX to get more colors for advanced blue lights. And i have to reload water and some other textures into RDVOX just to have them translated nice to new palete instead of having darker or lighter colors ingame. So can you make the engine to transform ALL THE RESOURCES with different paletes (loaded from doom/doom2 itself too)on the runtime into the last loaded palete? Then i will have not to add new textures to compatibility wad each time someone wants to play a custom boom or vanila wad that includes some new blue textures with RDVOX. This will save a lot of my time, nerves and improve picture in lots of pwads played with my mod, and may be not only my. For example remove from rdvox's PAL3PTCH.WAD all resources excluding PLAYPAL and COLORMAP and try map02 of doom2. Look at water. Look an blue door sides...
  3. Well, man you use Open GL i see. I have no idea why does it changes the sky to black. There ARE some issues with palete using side wads with custom blue textures but that isn't it. I am still vorking over lost soul graphics. The current screenshot is transforming pixel-by-pixel from idle to atack, by the eye method. And when i got this picture i got an idea to save the quad-eyed skull for future, mat be, trash, projects:
  4. i thought about new sprite. But i am not sure that i can create something better then this now. So i will come back to this later, when i will understand - what actualy i need
  5. Well looks like i will make it like in Rage 2 - there the bfg looks similar to dooms one. or remake it into a hi-tech butt
  6. Link? Looks like i dont know what are you takling about(
  7. Today i was improving those 2 idle/chase frames. I added a little light above chicks, and a layer of dots from right and left. The most changes were in the place where model contacts with fire effect: and so we get this prety color transition: Another thing i plan to add to 0.39 is BFG9K. It looks like a sprite from the side: But if we come and look closer we may see some more: I still can't understand what are those metal trims on the back(in the left of screenshot)
  8. I have some progress with lost soul. I hgave 2 frames finished, they have minimum difference and replace A and B idle/chase states. So i made some tests of combining this voxel and a flame from red torch. Looks like that vorks:
  9. Looks like i havefinished that kebab... That was not easy %)
  10. I have allready tried FPCDoom.Actually i thought it will runRDVOX like Delphidoom does. But it couldn't that time. This was in december 2019. I didn't like a lot R4G4B4 there - looks worse then the predefined 256 indexes. Anyway, i belive - you know what to do) I always wish to see as low sys requirements as it is possible, ZDoom based ports had that. But they have some strange problems when applying voxels to some classic/prboom wads, problems with scene z-sorting. I belive in delphidoom. The last release had nice performance. the only serious issue was that green color everywhere :D So i hope you will found a way to optimize delphidoom even for singlecore CPU's. BTW i collect some old cpu's, run doom sourceports sometimes on them, and not only. However, the 2-core processors that I usually use are now considered obsolete too. I think i gonna try Delphidoom on Pentium 2 for Slot1 with 320-512mb SDRAM as soon as i will find a compatible hdd for that =)
  11. I am asking myself another thing. if you plan udmf, and it has custom sector color (lightcolor) parameter - will that need enlarging of colormap twice for each next sectorcolor? or we make easier by just calculating anything in sector color BEFORE translation to 8bit palete? Imagine that we need just to render whole scene in rgb, applying sector colors, applying damage or pickup fades. As usual in 32bit. And only then we translate to final 8bit palete. Isn/t it a way to solve? Or this is cpu-heavy way?
  12. Isn't there a way just to precalculate all those damage red-faded tables and pickup yellow-faded tables? why do we need to do it realtime while the engine may do all those calculations using the LAST LOADED CUSTOM palete once at runtime?? Another idea, if previous is not working is not to make "fixed but slow" and "unfixed but fast" releases but to do it as an option. Can not you?
  13. GRAU

    What device do you use for aiming & turning?

    Usual wired mouse on a desktop computer, wireless mouse for floortop pc)) Sometimes Dual-Shock style gamepad for playing games like silent hill 1-4 or something from NES
  14. I got strange experience during redefining dynlights in new version. 8bit renderer drags nearly any yellow/softyellow dynlight color to green colors fromn palete. I even looked how qzdoom does this. But there is no such effect. color 1 0.7 0.3 color 1 0.6 0.1 color 1 0.5 0.2 (even 1 0.5 0 and 1.0 0.6. 0) - all those colors have not to look as green. We have lots of brown, orange, even some yellow-red in palete, i even tried to add some more yellow... but why do i see this: 1 0.7 0.3 - Column (light column) Delphidoom QZDOOM Candelier, color 1 0.6 0.1 Delphidoom QZDOOM Candle, color 1.0 0.5 0.2 and even torch that is nearly red - 1.0 0.4 0.1 - we have pinc colors, we have orange - why border is green? Delphidoom QZDOOM Please try to do something with this, may be add some menu for changing color-preference logic.. we need more experiments i think. I want to see delphidoom as a best sourceport, at least for playing classics with some lights and voxels)
  15. That is not a problem. But i got another one. You said i jneed a flag +passmobj and a lower then 30 height to jump over a barrel. I did it. Just look what i got: When i try to jump over a barrel - anything is nice. But when i try to jump ON a barrel - can. But i cant move there. I cant walk over a barrel. I set the height to 20 and radius up to 32 to show this. Both player and barrel has +passmobj flag. If i jump on a barrel - i can stay but trying to walk or to run, allready staying on an object looks imposible. The inimation is looking like the player is running all the time i stay on the barrel. But when i try to jump out - it pushes me out with a great speed. Like all the movement i had to do is stored somewhere untill i stay on a barrel and thei is given momentaly to a player! I added the files lower RDDVOX.zip RDVXTEST.zip
  16. The song is good, but i think this wad needs more scary ambient, more suspense. But songs themselves are realy good. I didn't know about tall textures. Didn't think about that. How heavy is this problem? may it cause crashes?
  17. Tested. Thank you a lot! Works fine.. Looks like now i can start the letsplay) edited later: I tried to record using this version. Anything was looking nice until music restarted. It restarts with a full volume. This kicks ass a lot when recording a letsplay. May you fix that? Another thing i could like is selection of midi (or may be wave audio too!) output device. And an ability to disable music at all. And another problem. I trapped into an imp and game freezed and then bailed out when i tried to shoot. Looks like i have to wait some more time till recording khorus. I'll wait until you finish true 3d gameplay options, enable shooting with a hitscan into a floor, and fiz music, no matter how long this will take) About attacking being too close to an enemy. Sometimes i see how arachnotron attacks mancubus. When they are too close (on a demo map), and projectiles are physicaly spawned inside another minster - the particles of a shot cannot fly apart in horizontal, but only can be pushed out vertically. Do i need a specific flag for those part-actors?
  18. Houston we have problems! I tried last WIP - in software renderer we have heavy fps drop on every item or powerup pickup, takin damage or any other palete-based effects( Mat be would be better if you returned the precalculated colormaps for those things. Just use that one included in last loaded wad - i have one in RDVOX, doom 2 and every game has a colormap with subtables for damage, invulnerability and pickups. I dreamed to start a letsplay from this release but looks like i couldn't. Even using twice more powerfull cpu will not solve this problem - it looks like a microfreeze on video, but it interrupts gameplay. Tried on Core2Duo e8400 and Pentium D945. BTW this problem does not appear in truecolor mode. Only 8bit. I think you could solve it easy. Another issue appears in GL renderer. The additive translucency looks strange, all black areas from sprites are rendered as non translucent at all. The translucency is ON in options. I removed as muck black borders from sprites as it is possible, that thin black-looking area in screenshot is not black actualy - i checked. Do something with all this, please.
  19. I have some news. I've done a few experiments and got a pretier graphica for imp and mancubus balls: The fireballs becam,e more firy, more red, so now they look more like original graphics, i think. Another one is... Yes. it is voxel lostsoul in progress. I'm not sure if this is a good idea, but i'll try to do my best.The main problem is animation. Another one is in combining this voxel head with sprited fire tail. I have added a little original view, adding orange fire on the chicks. If it will look worse ill remove it at all, and reave mourth as a deadly bloody danger full of pixel teath)
  20. GRAU

    When do you plan a next WIP build of delphidoom? I'm realy waiting it to start Khorus.wad letsplay using delphidoom and latest RDVOX. And another question - which os and software do you use for developing and compiling Delphidoom?

    1. jval

      jval

      Newest WIP 20200112 is out :)

      I'm using Windows 10 and Windows 7, DelphiDoom can be compiler with old versions of Delphi (Delphi6/7/2006).

  21. well grayscale voxels offcourse may be used too as brightmaps. An interesting idea, i saw something like that in some gzdoom pack for opengl only. Well, if we had this working in software, ill use it as much as it is possible. I like that there is no need in using the 6bit or table based calculations as option for lights. Absolute! We have doom in doom (usual delphidoom) for classic maps and prboom, and when i need advanced mapping i'll anyway prefer UDMF, because it has flat alignment, sector colors and many others i use often in my maps.
  22. Wow! Now this really looks great! A little bit - and shall start to convert my mod from zdoom to delphidoom) Waiting for the next release) I got an idea! You wrote above that May be you could add an option for that - Light calculations accuracy: (pre calculated tables (based on last palete loaded from pwads), r6g6b6, truecolor (r8g8b8a8)) I actualy do not know a lot about that but i think usage of lower bit depth calculations may give more performance. Or not? Another thing is that now lights do not effect on voxels in software mode. I think this is wrong. Voxels could be lit with dynlights like sprites (single light offset for whole model), or may be even side-orieted in future. I would like to see a precise lighting of voxels, depending on distance, direction, may be some normal-style calculations one day. Another idea for voxeldef is fullbright color. For example we may define some index(or index range) and set them Fullbright or Fulldark for this object. This may be used for bright eyes or some areas on light sourcxes that use to be allways bright (lamp in a lightg source), or may be even we could define light multiplier for some indexes. for example: indexmultip [index in voxel palete], [ammount] voxeldef "talltech.kvx" { replaces sprite "tlmpa" fullbrightindex 48 - will make color 48 always bright indexmultip 47, 1.6 - will increase by x1.6the brightness of all pixels using color with index 47 indexmultip 68, 0.5 - will increase by 0.5 (in fact decrease twice) all pixel using color with index 68 } i have much more ideas for future, but first of all i would like to see voxel affected with dynamic lighting, 3D water, translucent 3d floors, sector light colour and more advanced mapping format (for example like zdoom - doom in hexen or udmf) - to define all those things using GZDoom builder or doom builder 2.
  23. Well, looks like it is time to present you the version 0.38, non-alpha. Download Links: (Q/L/G)ZDoom: http://rdw.xp3.biz/RDVOX/RDVOX-0.38.zip Delphidoom: http://rdw.xp3.biz/RDVOX/RDDVOX-0.38.zip Updated testmap: http://rdw.xp3.biz/RDVOX/RDVXTEST.wad Things added in last few days: Video prewiev:
  24. I think it has to be default, yes, at least for delphidoom map format. Also i wanted to ask for some changes to default config - please ENABLE translucent sprites, DISABLE dithering translucency in 8bit, and more.. I tested, and tested and got interesting observations. looks like Delphidoom needs changes in colour levels. I mean - look please at this 2 screenshots. QZdoom and Delphidoom. The same lights. The same sizes. Both sourceports use default light config (100% intensity) QZDoom - the light looks darker, and much smoother, more natural. But not only light, i found. Look at color brightness levels. They are much smoother too. Looks like it has twice more lightlevels then delphidoom. (not divided by 8 brightness points but maximum by 4) I think that is the reason why picture in software and particulary lights look so smooth. It may mean that ZDoom-based ports ignore basic colormap, creating it's own, or something like that. Delphidoom. I have one more idea why lights look worse. May be the reason is that delphidoom aplies lights by adding the ammount of color to the final picture it has AFTER rendering the whole scene scene without lights but with complete distant shadow(fog). What if you try to apply lights to unshaded textures before applying distant fog/shading? I think it may help. Another idea is using light dithering between the indexes, the same you do for translucency. I even tried to get nicer effect by adding color intensity up to 137% but it still was looking weak.Try to look at QZDoom 2.0.0 sources, why nit? may be you could understand - how does it get so smooth picture, using only 256colors? Another one problem appears when i pickup something - looks like colours go out of palete in this moment: Even more - there is no white in palete i use with RDDVOX, and there is no saturated, dark blue there, but i see them in the screenshot. May be delphidoom uses original doom palete in this moment? And even more - may be i am the only one who has this problem (it was from the moment of first run, and it appears on both PC's of my)
  25. Well, looks like i have fixed all the problems i had to, and on the way to release RDVOX 0.38 (full) as far as i finish this lamp: And here are some of inovations i added to this version: 1) mancubus missiles/fireballs. I prefer to think - they are kind of flamethrower shots, gasoline balls may be) Another one is improvement of arachnatron plasma - it is not heading to blue colors near its center, but to yellow sometimes, and small green particles are result of plasma collision with something, but i am still at balancing the radius and color of lights, to give nice effects and nice performance at the same time: and the bosscube - i have 2 versions now - the usual looking one and a bit damaged one - look it bleeds somewgere, and somewhere has decals looking like bullet or sharpnel hit. I prefer to say that it is not damaget but a painfull one. Will you prefer such changes?
×