Weekly progress update, didn't feel like I did too much, but this is something. -- Changed an error where the Solfege shopkeep incorrectly refers to the band as "girls" despite clearly seeing Mezzo as a boy two other lines in. -- More progress done on the front of the rehearsal days. -- Changed up the music for when it starts snowing in Arpeggio pass, I would like to keep the music track for Aubrey's theme as intended.. -- sporadically adjusted a few portrait choices for characters in cutscenes -- Mapping for spoiler-worthy-stuff. -- Rewritten some sequences in the new, empty manor map of Bel Canto (pic related). Old version (and new version when implemented) of the writing are viewable by interacting with three spots while either Saki or Marybelle are in your party. Marybelle joins your party temporarily during the post-rehearsal sequences of day one and two, but not day three.

Weekly report >Implemented bladder for pioneeres >Implemented framework for AI >Fixed collisions here and there >Added show emoji action

Progress: >Added new enemy >Added AI for it Framework turned out nicely. I wrote like 5 lines of GDScript to make it work. >New death animations, thanks to pixel artist

- Day 2 progress : rehearsal sequence complete - Day 2 Post-Rehearsal still in progress, dialogue is laid out, cutscene pathing and other event semantics will be continued. - Day 3 dialogue almost fully laid out. - Squashed a bug in Teagan's room that continues displaying Teagan from the post-move-in-sequence of Bel-Canto. - Working on mapping for polyphony's new guard-station/jail. - Laid out some sparse normal NPC dialogue for the secret-final-arc. Little things that will make everything come together, and are best gotten out of the way now. - Audio software and tools set-up and ready to start producing. No guarantee I'll actually get to that this month or september. Art will be more important once I get my dialogue progress to act 2.

Small update for today. Had quite a few missed dev-days due to IRL getting in the way. - Day 2 post-rehearsal progress continued. Rewrite of Saki's backstory implemented. New Graveyard cutscene implemented. (pic related) - Updated raw writing for Act 2 Pizzicato Trail revisit. Holy shit, Bel Canto's finally coming along, I'M GONNA MAKE IT!

HOO BOY! I thought I wasn't getting much done this week like last week, but HOLY FUCK! The crunchiest scene in the entire rehearsal set is done. Now, day 3 I unfortunately cannot show much to you due to just exactly what that scene sets up, so you get an angry-stare-Teagan instead. On another note, due to the logistics required for the upcoming cutscenes, The Cantabile manor has it's front yard trimmed. -Day 3 Rehearsal cutscene complete -Day 3 post-rehersal cutscenes have the script implemented, -Picked out a temp track from Tales of Symphonia- Judgement of Mana, to put in place as Metronome Tower's music. -Script progress for act 2 updated, specifically, some emotionally-raw moments for waifufags. Gotta have those to make the upper moments all the more sweeter you know.

Hey everyone, this update I've felt like I'm made a good chunk of significant progress. Which is nice, because I'm gonna take a little break from gamedev to flex my drawing muscles on a small non-UT project I've been putting off. Weekly Progress Report -Added in about half of the day 3 post-rehearsal cutscenes and events. It's a dialogue-heavy day for sure, but I hope the pacing keeps things from dragging on. -Edited Bel Canto's inn to be 1. more fitting of the high-class-town area, and 2. to accomodate space for new cutscenes. (Pic related) -Changed Mezzo's class title from rhythmist to percussionist. -Added in an act 2 boss fight to the debug room. Spoiler-heavy. Ingame, it will be skippable as to prevent what would be a soft-lock for that area. -Added in in events that store recovery items away during Glissando Arena. Not fully implemented of course, but it should be implemented come the Nuclear Teagan release. See you the 28th!

A got a bit more on track. So, weekly report. >Added interactive popups >Added cockpit >Made essential buttons work >Fixed bug with interaction, some anon pointed out

tme to get wet

>>321 >1st video >water effect It's particle system or some kind of animation ?

Weekly report >Added energy bar >Added energy

Weekly Progress Report - Back from side project dealings. Ended up changing gears to something different than drawing, but no biggie. - Did some writing for Act 2 and 3, specifically post-party-split dialogue, and Arietta's Uncommon time. Back in business, time to get shit done.

Yeerk's weekly >AI now can react on Yeerk I was hoping to also add attack, but unfortunately it stays for the next week.

Uncommon Time Rewrite Progress Current Progress report -Continued with raw writing for act 2 and 3. Getting close to completion. -Drew some initial concepts for the ex-worm and ex-faggot. Not much done for the current playable progress of the game, but since I got art to eventually do. Pic-related, is a super-deformed imagining of what the faggot and the worm will now look like: Sakarias "Saki" Toikka, The wild-man. Auberon "Aubrey" Spica, the faerie-halfing from long-ago. this is not the intended artstyle, this is something silly and without anatomy perfectionism so I can show you characters at their most-basic form

Yeerk's weekly >Still working on attack Animation is in place, but no hitbox yet and no mechanism to exit the state.

>>326 Uncommon time Rewrite Weekly Progress Report -Changed up character class names; only the Cantabiles will have musician-themed class names. -Continued progress on day 3 post-rehearsal cutscenes. pic related -Added a reset button for Metronome Tower's pre-boss area to prevent a potential post-cutscene soft-lock. -Certain Act 2 writing sequences put in limbo for now. Not technically cut, but close to the chopping block and I'm hesitant on it.

After two weeks instead of one >Pineeres's attack is finally working >Yeerk is dying I've had to implement additional animation system that is unrelated to movement for that. Pretty happy with result. Core mechanics are almost done. Hope to finish them next week.

>>328 since the cafe was down last time I was doing weekly updates, this one is a bi-weekly plus one day because yesterdayt was not worth uploading on. No screenshot either because nothing I've done this week is really worth showing. Weekly Progress Report -Finally got around to downloading inkscape and testing shading on it. My aim for this week is to draw a character and get a completed art piece out to you guys so I can show "yes, I can do art, and at the barest of minimums have it not be shit". -Crushed the rest of the unformatted nametags in Nuclear Teagan. -Crushed unformatted nametags in Glissando Arena.

Yeekr's weekly >Implemented reaction on dead bodies >It's now possible to eat pioneeres Art guy was busy so visuals aren there yet. Shouldn't be a problem though. Main mechanics are ready. It makes me happy. I plan on making 1st level by the demo day.

>>322 sorry dudem missed your question. It's an animated alpha map

DEMO DAY currently underway on these boards: https://zzzchan.xyz/v/thread/18328.html#18329 https://8chan.moe/v/res/149845.html post your stuff, repost here: >>338

>>336 can you reupload anon i know im days late but i wanna try your game been looking forward to it

>>341 sorry about the wait. here's the more refined demo. https://shodanon.itch.io/peripeteia/download/i7bzqNEKmw6JJ_JwEOYbEoAvVbJUhnPVA5Efab9_

>>147 Reminds me of Deus Ex. What's your game called?

>>344 >>351 this is the game

>>123 Does this board have a Board Owner?

>>368 I ran the original 8chan board for a few years, while the anon.cafe one had a different owner for a while. I jannied here, didn't log in for a long time, now I discover it has been transferred to me. So the answer is "yeah, it has one".

>>253 Start writing code threw a language in an engine,I say this by experience it much more modifiable and easy in the long-term.

>>370 Congratulations, I guess.

Downloaded Unreal engine 5 to mess around and make a game or two. Got nowhere with it yet, since I'm starting from scratch. Anyone else using unreal 5?

>>123 Can I use this space to bounce ideas off?

I've started several projects (games and visual novels). I'm not quite sure which one is good enough to be worth finishing. You can find almost all of them on: qrayz.itch.io

>>451 HackSim seems like a good concept to put in a game instead of the typical hacking minigame. I didn't try the others, especially the VNs since they rarely feel like games to me, maybe I'll get around to them later.

Finally got A* path-finding working after a couple of days of banging my head against it. Test program here is done with Raylib.

>>477 based raylib user, how are you liking it?

>>480 It's a true joy to work in. I'd recommend it to anyone, really. Dead simple to use, only needs a single header included, no cumbersome build system, with tons of useful built-in functions (all optional, mind you) with straightforward interfaces and a minimum of proprietary objects. To any beginners out there still fucking around with SDL2 or SFML or god forbid, raw OpenGL, you gotta switch over.

>>481 >To any beginners out there still fucking around with SDL2 or SFML or god forbid, raw OpenGL, you gotta switch over. Does it have support for things like sound, networking, and concurrency?

>>529 Raylib is a single-header library, so I'm sure it'll play fine with your threaded and networked application. That said, neither of those are 'built-in'; you would need to provide your own. Sound, however, is very well supported, see 'module: raudio' on the cheat sheet: ht tps://www.raylib.com/cheatsheet/cheatsheet.html As far as networking goes, no it's not included right now. See this thread about developing a networking module for Raylib and the solutions users came up in the meantime: ht tps://github.com/raysan5/raylib/issues/753 People seem to like enet: ht tps://github.com/zpl-c/enet ht tps://github.com/nxrighthere/ENet-CSharp Here's an example of using enet with Raylib: ht tps://github.com/JeffM2501/raylib_networking_example nbnet was also mentioned at the bottom but the link was dead there so: ht tps://github.com/nathhB/nbnet Just gonna drop this here for everyone too - giant curated list of game development libraries: ht tps://github.com/Caerind/AwesomeCppGameDev World's your oyster, mates. As for threading, CPP has had concurrency support since C++11, and using posix threads (pthread.h) should be supported by all platforms. The trick to threading, of course, is all about resource access, as long as you aren't trying to access a resource (something in RAM, the GPU, whatever) with two threads at once, you should be alright. So while trying to render a complex scene using two or more draw threads will absolutely fuck your shit up, using a thread to calculate updates to game state (pathfinding, line-of-sight, physics, sound, background resource loading, etc. while your main thread is going through all your draw lists, you should be alright. You also have to ask yourself, "Do I really need concurrency in my game?" Even toasters today have 3+ GHz processors pipelined miles deep. I guarantee you can see better than the 2-4x speedup of threading by just fixing your approach somewhere. Got 300 entities recalculating their pathfinding every frame and struggling to hit 60 FPS? List them up, and update 30 of them every frame, in round-robin fashion. Now you're updating everyone's path 10 times a second instead of 60 and your shit's 6x faster. Stuff like that. If you're even considering raylib for your project, I really wouldn't worry about threading. Look at the complexity and speed of games in the 386 to pentium 4 era and look at the processing power we've got today. You could absolutely make a Quake-like in Raylib if you wanted to. As long as you don't write your shit all retarded, you'll be alright. Here's a really basic threading example for raylib: ht tps://www.raylib.com/examples/core/loader.html?name=core_loading_thread

>>530 Great reply thanks. I'll look into it now.

Was curious about the state of DOOM-style BSP engines since I still see so much chatter over modding and source ports and shit. Went looking for some actually free code and found something called rtdoom over on the shithubs ht tps://github.com/mausimus/rtdoom Took a few minutes to change a few things to get it to compile on linux with GNU Make and somehow it worked. Dropped in some WAD off freedoom and this is the result. Occasional visual bugs like in the last pic and Z-level movement isn't handled too well but otherwise ran ok.

Playing around a bit with 3D in Raylib. Loaded a mesh from an OBJ file, then rendered it at 320x240 and scaled up 3x for a kind of old-school, PS1 look. First shot is with the old 512x512 texture, second is scaled down to 64x64 and contrast tweaked a bit to bring out some detail. If I get some free time again I think I'll try making the camera first person and use a vertex lighting shader too.

>>583 Oops, had bilinear filtering on for the last 2 shots. These are more what I was going for.

>>585 Now with affine texture mapping by adding "noperspective" interpolation qualifier to the default vertex and fragment shaders. Next I gotta find a more complex model to try it out on.

>>586 Since they won't upload: base.vs #version 330 // Input vertex attributes in vec3 vertexPosition; in vec2 vertexTexCoord; in vec3 vertexNormal; in vec4 vertexColor; // Input uniform values uniform mat4 mvp; // Output vertex attributes (to fragment shader) //out vec2 fragTexCoord; noperspective out vec2 fragTexCoord; out vec4 fragColor; // NOTE: Add here your custom variables void main() { // Send vertex attributes to fragment shader fragTexCoord = vertexTexCoord; fragColor = vertexColor; // Calculate final vertex position gl_Position = mvp*vec4(vertexPosition, 1.0); } base.fs #version 330 // Input vertex attributes (from vertex shader) //in vec2 fragTexCoord; noperspective in vec2 fragTexCoord; in vec4 fragColor; // Input uniform values uniform sampler2D texture0; uniform vec4 colDiffuse; // Output fragment color out vec4 finalColor; // NOTE: Add here your custom variables void main() { // Texel color fetching from texture sampler vec4 texelColor = texture(texture0, fragTexCoord); // NOTE: Implement here your fragment shader code finalColor = texelColor*colDiffuse; } relevant bit in main.cpp: Shader shader = LoadShader("base.vs", "base.fs"); Model model = LoadModel("crate.obj"); // Load model Texture2D texture = LoadTexture("crate1_diffuse_small.png"); // Load model texture //SetTextureFilter(texture, TEXTURE_FILTER_BILINEAR); model.materials[0].maps[MATERIAL_MAP_DIFFUSE].texture = texture; // Set map diffuse texture model.materials[0].shader = shader; // Set material shader

Well, shit. Ifrit was a little hard because he came upside down, scaled up 1000x, and needed two diffuse textures but otherwise they're just plug and play. Models grabbed from ht tps://www.models-resource.com by the way.

>>588 An attempt at lighting. Looking a little washed out, think I set the ambient light value too high. Shame too though, it appears the lighting model from here ht tps://github.com/raysan5/raylib/blob/master/examples/shaders/shaders_basic_lighting.c is Phong (per-pixel specular) and not the more period-accurate Gouraud (per-vertex). Gonna have to read up on lighting models and shader code to see if I can't change that, though I did find some code here ht tps://garykeen27.wixsite.com/portfolio/gouraud-shading that might do it.

>>589 Maybe you clipping maximum brightness for a texture. 200red50green50blue+150 white=255red,200green,200blue, which is almost white. if Can you change shader, so its capped by the original texture values? That way stuff could only become darker, but never washed out. Try rendering some gradients to look what is going on. However washed up look is quite common for simple light engine in games, like in fucking dark souls 2.

>>590 >clamping colors in the shader I player around with that, didn't fix it. The problem ended up being color space and gamma correction. Turns out I was using sRGB color space PNG images for the textures (which is normal for images meant to be displayed as-is on a monitor) and the final step in the fragment shader was applying gamma correction to convert from linear color space to the sRGB color space expected by the monitor. The double conversion was causing the washout. Commenting out the gamma correction resulted in something somewhat closer to correct, but that wasn't a proper fix. It turns out color and lighting calculations need to be done in linear color space for the math to work out right. The proper way to do it is to either use texture images that are already in linear color space (GIMP can do this for you, see pic related), do calculations, then gamma correct OR, use sRGB color space textures, convert to linear color space in the shader, do calculations, then gamma correct back to sRGB for display. In the side-by-side comparison shot, you can see I've done that in the 3rd and 4th pics, resulting in (virtually) identical outputs. The other images are all incorrect in some way or another. See references for more information and the shader code I borrowed for the color space conversion. The final fragment shader ended up looking like this: #version 330 // Input vertex attributes (from vertex shader) in vec3 fragPosition; //in vec2 fragTexCoord; noperspective in vec2 fragTexCoord; //in vec4 fragColor; in vec3 fragNormal; // Input uniform values uniform sampler2D texture0; uniform vec4 colDiffuse; // Output fragment color out vec4 finalColor; // NOTE: Add here your custom variables #define MAX_LIGHTS 4 #define LIGHT_DIRECTIONAL 0 #define LIGHT_POINT 1 struct MaterialProperty { vec3 color; int useSampler; sampler2D sampler; }; struct Light { int enabled; int type; vec3 position; vec3 target; vec4 color; }; // Input lighting values uniform Light lights[MAX_LIGHTS]; uniform vec4 ambient; uniform vec3 viewPos; const float SRGB_ALPHA = 0.055; // Converts a single srgb channel to rgb float srgb_to_linear(float channel) { if (channel <= 0.04045) { return channel / 12.92; } else { return pow((channel + SRGB_ALPHA) / (1.0 + SRGB_ALPHA), 2.4); } } // Converts a srgb color to a linear rgb color (exact, not approximated) vec4 srgb_to_rgb(vec4 srgb) { return vec4( srgb_to_linear(srgb.r), srgb_to_linear(srgb.g), srgb_to_linear(srgb.b), srgb.a); } void main() { // Texel color fetching from texture sampler //vec4 texelColor = texture(texture0, fragTexCoord); // get texture color as-is vec4 texelColor = srgb_to_rgb(texture(texture0, fragTexCoord)); // get fragment color from texture and convert to linear color space vec3 lightDot = vec3(0.0); vec3 normal = normalize(fragNormal); vec3 viewD = normalize(viewPos - fragPosition); vec3 specular = vec3(0.0); // NOTE: Implement here your fragment shader code for (int i = 0; i < MAX_LIGHTS; i++) { if (lights[i].enabled == 1) { vec3 light = vec3(0.0); if (lights[i].type == LIGHT_DIRECTIONAL) { light = -normalize(lights[i].target - lights[i].position); } if (lights[i].type == LIGHT_POINT) { light = normalize(lights[i].position - fragPosition); } float NdotL = max(dot(normal, light), 0.0); lightDot += lights[i].color.rgb*NdotL; float specCo = 0.0; if (NdotL > 0.0) specCo = pow(max(0.0, dot(viewD, reflect(-(light), normal))), 16.0); // 16 refers to shine specular += specCo; } } finalColor = (texelColor*((colDiffuse + vec4(specular, 1.0))*vec4(lightDot, 1.0))); finalColor += texelColor*(ambient/10.0)*colDiffuse; // Gamma correction finalColor = pow(finalColor, vec4(1.0/2.2)); } references: ht tps://en.wikipedia.org/wiki/SRGB ht tps://learnopengl.com/Advanced-Lighting/Gamma-Correction ht tps://github.com/tobspr/GLSL-Color-Spaces/blob/master/ColorSpaces.inc.glsl ht tps://www.shadertoy.com/view/lscSzl

>>592 The textures in question - you can see the linear color space ones are darker and a bit "black-crushed". Or not, it looks like they're being converted to sRGB on upload.

>>593 Nevermind, they posted more or less ok.