Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

jfkEO1010etc

195
Posts
16
Topics
19
Followers
19
Following
A member registered Dec 27, 2020 · View creator page →

Creator of

Recent community posts

I have no idea. I even don't know what speed's DX7 dll is. That said, displacement mapping is the only kind of quasi bump mapping that I really like. B3D has only dot3 / normalmapping. I sometimes use masked textures to "bump" a texture, but it works only when Y-offset just a tiny bit. And then it's barely noticeable.

Currently working on better bushes etc. for relic hunter, pls give some feedback. The longer I work on it the less I can tell whether it actually looks better generally. Those old ones had like 16 triangles, they couldn't be shaded without to reveal the cheating. The new ones (basically just a mushroom aligned bunch of 4-sided bottomless cones) give more detail and depth, yet they lack of a kind of self-illumination you would expect... when you look at these things for too long, it's like a painter going out of creative mode, becoming 100% technical.

Wow I just used the word "fix" 6 times ^^

I usually bought map content too, when developing more complex things. It would take me years to design all the maps for a full 3D game. So that's fine. Hope you don't mind I watched only the screenshots - may I ask, what is rendering it?

Great to hear. It looks so organic: when it's too steep, soil won't stick, hence no plants but only rock. And that by a single click.

Didn't try it but it reminds me of the time we had vertex alpha splatting textures on terrains, but barely any Gui whatsoever. Maybe consider a feature like automatic height mapping (water, permafrost etc), and very cool is to map steep slopes by rock and the more flat terrain by grass, then procedurally distribute plants on the grass areas only.

Beautiful!

This one is pretty obsolete and still contains string.replace() where string.replaceAll() should be used. Better use the online version of BB2JS. Develop in blitz 2D, following the special rules for BB2JS, then copy paste the two parts (init and main loop job) to the browser at https://jfkeo1010etc.itch.io/bb2js-online-version . That said, it does not use WebGL, but plain 2D canvas commands.

It's a decade ago I purchased the FastExt lib, I didn't even remember they had this. But yes, the alignment of the effect should still be fixed, it's not logical by now. If the effect is fixed to an object like the sun, you can lower polycount and texture size of the ray mesh. But Somehow I like the screen filter approach, that fixes the filter to the camera. It just really needs a fix that adjusts the angle and position, so certain camera motions don't make it look unlogical. Right now I am more concerned about optimizing the render time, fixing the effect angle etc. I save as the easy part as a dessert. 

Also, small texture size causes flickering rays because of marching pixels (and the KIND of pre-mipmapping in the dds texture has an impact, masked textures flicker more with the sharp "next neighbor" method), a blur of that render might fix it, but it's costly, or yet another  challenge.

Thank you! The performance of the effect is one thing, but the performance of the whole scene / engine is yet another to-be-optimized issue. I have just realiszed that I didn't follow one of the most important rules: keep the surface count low. For instance, 7000 Grass meshes (2 quads x-ed) that are made with copyentity and via a contingent placed and oriented around the camera, are still 7000 surfaces, a huge impact. I just optimized it here from 20fps to 30 fps on my little card, simply by kicking the contingent system out, create 70'000 grass meshes, and 10x10 dummy meshes that are distributed evenly over the area. Then I addmesh the grass to the dummies, depending on their location. This way the grass is split up into 100 segments, each one containing only 3 surfaces, because they are 3 different brushes / grass-types. Directx does that, when you addmesh things together, it will optimize the brush count by reusing already existing identical brushes and adds the mesh to the corresponding surface,  keeping the surface count low. The camera range can then exclude a lot of the grass sectors easily. It really speeds things up. I'll do the same with the trees and bushes get rid of the LOD system. Funny, it started with the LOD. Trying to get better grass, testing some alternative ground, I'll add a screenie.

Whether Render to texture is faster than copyrect I don't know, but in theory, when you render to the texture, you can skip the copyrect part, but you have to render anyway. So I guess yes, it might be faster, even tho, copyrect 256x256 to a 256-flagged texture was like 1 or 2 ms only here. I guess optimizing the scene as mentioned has a bigger impact. Esp, since the scene is rendered twice.

(1 edit)

Maybe I'm wrong, but as far as I remember Blitz3D doesn't support Render to Texture. The addition of Flag 256 allowed for faster access ("Store texture in vram"), but no direct render to texture. Copyrect from backbuffer to vram-texture is rather fast tho. Lockbuffer is slow and the actual problem. A way around would be:

render actual scene, without rays.
render mini version 256x256 and copyrect to texturebuffer (optimized with details like grass hidden)
render rays mesh alone ontop

This 3 render method does not allow for pixel access, so I'd use EntityColor 0,0,0 for shadow casting things, like in the source. Most important: no lockbuffer required. That should lower the 16 ms to 2 ms. The beauty of extracting the texture from the first render using readpixel etc. was, that its speed is independent from scene complexity, but well, it required lockbuffer, so..

edit: I just tried that, not significantly faster, unless I did something wrong. Then there was also a hack, to directly peek/poke VRam and Buffers, I guess using the memory.lib. Most likely not very stabile.

Fascinating. Add magnets and coils :)

It is the second release of relic hunter v 0.11, but the include file for b3dfile.bb is missing, but that's in the pine tree creation zip.

Either way, while the FestExt library by mikail seems distincted online, luckily I found my purchased version on the harddrive, containing RenderToTexture. If time permits...

That's from the last Relic Hunter prototype. However, adding it to the procedural forest source is relatively easy.

(20 secönds later)

Just uploaded the source, but no time to clean up, sorry.

Interesting, but a ray resolution of 256x256 would be 64k Linepicks which might be slow too. Below 128x128 it becomes really blurry.

My OG fell on its side, that was the end of it. How to restart? And where's Mike? ^^

Ok, in case anyone is interested: I tried the above idea (not the ASM part) and two things became clear: first of all, doing only one render inevitably causes a recursive feedback, because the points sampled are brightened and sampled again repeatedly, forcing me to use a very low alpha, but even then it stabilizes only due to rounding errors, causing it to flicker wildly. So I concluded there is no way around a 2nd render. 

However, I found a much faster way: Render the scene without the rays mesh, full display size. Then do the point sample from the backbuffer and move it to the ray  mesh texture. Then move the camera 10000 units away, where the entire scene is out of rendering range (the ray mesh is parented to the camera), set the cameraClsMode to maintain the backbuffer and now render the ray mesh alone ontop of it. Then set CameraClsMode to 1,1 again and move camera back to the scene. I was able to lower the rendering time of the effect from 23 to 16 ms - still very slow.

That's when I figured out the second thing: from the 16 ms about 13 ms were used only by the commands lockbuffer backbuffer() and unlockbuffer backbuffer() ! I tried it with no fastpixelreading, it took 13ms, then also without lockbuffer and it went down to like 1ms.

So the main bottleneck seems to be lockbuffer. It seems to wait for some green light from directX, which is in sync with the system framerate. I tried VWait right before lockbuffer and was able to lower it from 16 to 5 ms. But VWait should always be followed by flip 0, if used at all. Maybe I'll upload the source.

Great job.

Oh and BTW (also sorry for the text avalanche), as I'm thinking about it, I may as well try an entirely different approach that uses only 1 render: do a point sample mini copy of the main render from the backbuffer, eg. 256x256 pixels, then scale them down to 128x128 while smoothing the point samples (blur-shrink), probably using inline assembler (like you can in gfa basic, and probably freebasic that can make it a dll that then can be used in Blitz3D via userlib decls). And when reading the point samples from the render, ignore anything that isn't bright enough (or lower it to rgb 0).

Thanks. While it still is too much centered for an effect that comes from all sides (which is unlogical anyway, when you look at the shading of the trees), it could be faded in and out dynamically when one is looking at the actual sun, or where the sun would be. The effect adds only a few hundred Tris to the scene, and they are blended in in add-mode, can be put in front of everything with EntityOrder, so this ray-mesh isn't the bottle-neck. One thing that is slow is to copy this render to the texturebuffer, even with the 256-flag. Render to texture would be faster. I think I remember I was able to do that using the FastLib for Blitz3D. The other burden is the render itself. This can be optimized by hiding the grass and maybe the bushes temporarily. And of course, as mentioned in the code, using EntityColor to turn the trees and the ground black during this render, rather than using WritePixelFast as in this demo (which I do in the experimental version of relic hunter). However, in the end of the day it really is an additional render, just like a cubemap would be, or some other fancy stuff, so we have to take the polycount into account. That said, when I first tested the trees without LOD, I threw 600k tris at my cheapo onboard card (AMD Radeaon R3) and it rendered it like a 1-cube scene, I guess 60 fps. So I'm getting a bit wasteful in terms of polycount. Maybe 1000 Tris for a tree is still too much  (could be made less dense in the pine tree code). I guess DX7/Blitz3D still forces us to do more lowpoly as it lacks of certain FAST features, like shaders, automatic LOD, render to texture etc. But I can't help myself, I had unity installed, and mildly put, I didn't like it. Also, these days there are so many engines out there, I could spend my whole life just to test them, and from past engine-tests I know it usually gets you nowhere. Still, a Blitz3D to WebGL converter would be very nice.

Looking good. I'm working on something similar.

Hehe, I kept that disappointment moment at a realistic level - actually IRL we find 97% scrap iron. Here we have 500 nails and 500 coins buried.  Tho, that's still boring, but adding some special artefacts will be easy. And, like hints in the game, about where to dig for the real good stuff, and riddles that reveal locations etc.  And of course some nice ruins to explore. I can't wait to put moss on the bricks ^^ Thanks for playing!

The trees use the billboard LOD already, causing some pop-in artefacts. Bushes are only 250 pieces in the whole area, using EntityAutofade, and are very lowpoly. But a better LOD is due, admitted.

(1 edit)

The page keeps scrolling when i walk. Maybe it's just on this hp laptop.

edit: ok I see I can use WASD. But walking is very slow, like on ice. Maybe the movement is not frametime delta corrected. The camera script quality is under the design quality level, unnecessarily. Very nice design and sound.

Very nice, even tho I am having a hard time to grasp the playing principle, but I like the 3D style, and that X switch thingy.

^^ Thanks a lot! It looks better with some bushes, have a look at Relic Hunter, and feel free to use that bush mesh and texture that comes with it. (Scaletexture tex,0.25,0.25 to increase leaf count ^^)

Thanks. These days I use the free version of Artweaver (tho, it has a weird 17 seconds "initialization" pause when run), which substitutes PS 5 pretty well. I miss the .dss export plugin (intel or nvidia) tho, so I also have paint dot net, which is actually pretty good. And then there's Gimp and PhotoGimp. It's a miracle Adobe is still in business.

Yes of course me too. I was just comparing to what it sums up. Also, photoshop is less specialized, has more potential users. Not that you really need it tho, thanks to open source clones.

Being able to use the landscapes in unity or unreal engine would probably alter the whole job sector of game level designers, esp. outdoor scene specialists. Then the price would be way too low. Look at adobe how they cash in with photoshop., on a monthly fee basis. A further alternative would be if you provide it with a sciptable rendering engine, so people can use it to make games, but only with your licensed engine (eg. sales-dependent royalty). I must admit, it's tempting to use your tool for level design.

Very nice level design. Unique theme. Good luck with this project! May add a Ronin mode ^^

How to walk? WASD and cursor keys do nothing. And who's the girl? Those coppercube trees :) Placeholders I hope ^^ - Try my pine tree.

So true. Collision can really knock the toughest coder out, just like rounding errors. And those stealth chameleon bugs. Oh so that keys thing was just on my machine. Must be the hardware then. It's a touchpad, not a mouse, maybe that's it.

Thanks :)

Nice start. Probably needs snap2grid. Some areas of the black keys also play the next white key. I'd just check black rectangles first , if one is clicked, exit checking.

How about to sample the ground height under the camera and use it for what is now done with "E" and "Q"? I see I still cannot mouselook while WASD is pressed. You could have a look at my camera scripts for coppercube. While there is indeed a weird system bug due to which the mousespeed is reported lower when a key is pressed, it is still possible to get the mousespeed during key presses. And I think it is an integral part of FPS controls to steer and walk simultaneously. Anyway, keep up the good work!

Very nice job. steering with cursor keys left right is a bit too abrupt I guess. Nice damage mode on the car, nice physics.

Pretty good demonstration of weapons and physics. Add some interactive items (doors, , bonus, info, npcs...) and make a game. Bug: LockPointer not working.

looks like vertex-less procedural or fractal 3d rendering. fascinating.

cool