dulsi {l Wrote}:I don't think I've ever seen a substantial program written in lisp until looking at this. (Well you could say emacs but besides that.) Not sure if you will find artwork help here but I'm glad to hear about the project. I'll try to give it a test when I get a chance.
fluffrabbit {l Wrote}:At 250 vertices your bottleneck will be draw calls, not the renderer.
I see your engine uses a lot of Lisp stuff, so I guess you've been around for a while.
A screenshot in the thread might be a good way to build interest.
I am using instanced rendering to draw the most parts of dungeons, so i hope this very likely should not be a problem. I am struggling with blender (i can not wrap my head around this software :-( ) to fit a texture on the column and then i am going to try. I have to say that opengameart is a very valuable site for a lonely programmer with no art skills like me! :-D
Well i guess i am older than the average age population if i understand correctly what you have written!
I am starting using lisp just about ten year ago, though. I have used (and still using) a lot of languages before but i feel lisp (Common Lisp) is the one where the gap between the code in your mind and the code written on the editor is minimum, at least for me of course. (sorry if this sentence is not clear, my english is horrible!)
fluffrabbit {l Wrote}:Instancing -- nice! My current project unfortunately limits me to WebGL so I can't use those fancy GL/ES 3+ features for compatibility reasons.
I am starting using lisp just about ten year ago, though.[...]
Your English is good,
though your taste in scripting languages is questionable.
10 years ago Lua was the hot scripting language to learn. Now it's mostly JavaScript and smaller niche languages. I have always found Lisp to be a bit odd. My code these days is very procedural; comment, step A, comment, step B, tiny and extremely cautious chunks, not as lispy.
That is a very nice screenshot.
I see you have implemented normal mapping.
I also see what you mean about the art. Your pipeline can probably handle more physically correct materials so the red walls don't look overexposed.
It looks like lots of functionality is already in place, so the aesthetic stuff really will be adding polish rather than replacing what would otherwise be content. My games never have any depth before I start jamming them full of art assets. Unlike me, you seem to be doing things in the proper order.
i am curious about your project, can you tell me more or do you have a link for it?
I use javascript too but the syntax is sometimes confusing and prototype inheritance even more!
A great technique! There was an error in my code regarding normal map generation that was driving me crazy. But seems to me that the results is correct now. The bug inspired me an experiment: i would like to try to perturb the normal (in the fragment shader) with some kind of noise. Maybe i could try to simulate the lights waiving...probably this is going to results in a failure, i do not know...
i forced myself not to ask help from other people if the game was not feature complete, i do not want to waste other person's time. i hope they enjoy working on this project like i do!
fluffrabbit {l Wrote}:i am curious about your project, can you tell me more or do you have a link for it?
Sorry, it's not an open source project. I've got 99 problems and an ideology ain't one. Life stresses, basic needs, etc. Maybe one day...
I use javascript too but the syntax is sometimes confusing and prototype inheritance even more!
Funny you should mention that. I've always seen JavaScript as a little lispy, so my programming style in it was mostly functional with lots of nested brackets, for instance:
var a = ( function( b ){ var a = b * b; return a; } )( a );
It's awful... JavaScript lets you write weird/bad code, so I used it to write weird/bad code. In much the same way, Lisp also lets you write weird/bad code, but apparently you avoid that pitfall.
A great technique! There was an error in my code regarding normal map generation [...]
Not just normal maps but generated normal maps! That's pretty cool. I don't have anything close to that.
[...]
Regardless of when you show it to people, a lot of games are bare-bones button mashers with nothing to do but are full of polished art assets (from the programmer or downloaded). These developers, many of them using Unity, put 90% of the time into the graphics and don't really work on gameplay ever.
function square( num ){
return num * num;
}
var a = square( /* some number */ );
def square( num ):
return num * num
a = square( 5.0 )
fluffrabbit {l Wrote}:I'm going to ramble a bit. Sorry in advance.
Nowadays, "good code" is code that is easily readable [...]
- {l Code}: {l Select All Code}
def square( num ):
return num * num
a = square( 5.0 )
Python does not even allow block comments. Some languages do not allow default function values, pointers, or with/using syntax. Java requires fully qualified classes and functions.
function delay(f a) { return function () { apply(f, a) }}
Sobel operator, huh? That will highlight edges and probably works fine for procedural textures.
For textures derived from photographs, the ideal way to get a depth map is by taking the delta between two photos taken side by side (like your eyes do). Obviously that won't work if you only have one image. You could infer depth using convolutional neural networks, like with dlib for example.
square = lambda a: a * a
a = square( 5.0 )
Nice! I could actually try the first approach!
sudo apt install libnvtt2 ffmpeg
#!/bin/sh
nvcompress -tonormal -rgb screw_bump.png tmp.dds
ffmpeg -i tmp.dds screw_normal.png
rm tmp.dds
fluffrabbit {l Wrote}:A function within a function on a single line? You can't be serious.
fluffrabbit {l Wrote}:Python 3 indeed supports one-liner lambdas [...]
fluffrabbit {l Wrote}:Nice! I could actually try the first approach!
You could, but [...] Long story short, my technique sucks, as evidenced in this Eevee render. For some reason the site won't let me upload the normal map, but suffice it to say it's very noisy.
fluffrabbit {l Wrote}:Glad to hear you can push more polygons.
Definitely the language designer of python does not love lambdas. ;-)
I see. Have you used some sort of support for the camera? Like a tripod or something like that?
Yes but there are some small performance issues not related to this last change. :-/
fluffrabbit {l Wrote}:Definitely the language designer of python does not love lambdas. ;-)
No doubt. Users of Python seem to feel the same way. I'm more moderate on the issue. I don't like using lambdas as a universal solution because my brain isn't wired to read code, but I do use them when they seem like the best solution.
[...]Yes but there are some small performance issues not related to this last change. :-/
Such as?
GunChleoc {l Wrote}: [...]
I like to use them to get rid of code duplication within 1 function without having to clutter the interface with a helper function
I am rendering to texture to simulate water reflection, turned out that re-render the entire scene two times was too much for my CPU. I removed some non essential stuff from the rendering, in this second pass: there is no use to waste cycles when the results is just a bunch of blurred pixel. The CPU usage is better now.
I like to use them to get rid of code duplication within 1 function without having to clutter the interface with a helper function
fluffrabbit {l Wrote}:I am rendering to texture to simulate water reflection, turned out that re-render the entire scene two times was too much for my CPU. I removed some non essential stuff from the rendering, in this second pass: there is no use to waste cycles when the results is just a bunch of blurred pixel. The CPU usage is better now.
I need to catch up! Real reflective water is awesome. The other main techniques are screen space reflections and light probes, which might be more performant. However, assuming the instancing is happening with the graphics API rather than uploading vertices every frame, I don't know what would suck up the CPU time.
Users browsing this forum: No registered users and 1 guest