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

k8vavoom: no good thing ever dies! (2019, Sep 06 build)

Recommended Posts

Posted (edited)

Hey, 

I'm not sure if you plan to recreate or fix the net code in the style of vavoom for k8vavoom at some point.

But from the looks of it, it use to have a master server query option, if a master server is going to be hosted for it at some point, I'm not sure the protocol.

Otherwise if you don't plan to host a master server, you may think about the gzdoom or zdoom based netcode, but I don't want to talk you out of anything you have already planned for it.
 

String Netcode = possible zdoom based netcode;
if (possible zdoom based netcode == 0)
{
  utilize zdoom net code;
}
else
{ 
  it would be nice to have a functional k8vavoom master server;
}
FreeString(Netcode);

 

 

Edited by Mr.Rocket

Share this post


Link to post
Posted (edited)

sure, code to talk with a master is there. i am also planning to add support for DoomSeeker, and prolly create a generic socket interface, so one will be able to write VavoomC support for any master protocol.

 

but there is little reason to announce k8vavoom on any master yet, while netcode is such broken as it is now. ;-)

 

later, i can host k8vavoom master: i have static IP, so it is not a big problem. actually, my host name is already put as default master, but communications are turned off with cvar (and it will prolly stay opt-in, as i believe that such features should be "off" by default).

Share this post


Link to post

ok, a "birthady gift release" is here! i can postpone it indefinitely, so today is as good as any other day to push yet another public build.

 

brief changelog (please, note that changelog is not complete, and somewhat random; usually, there are more changes than mentioned in changelog):

* WARNING! networking code is completely broken for now. i know it, and i will try to restore it later.

* switched to mi-malloc, as it seems to perform much better with alot of small mallocs/frees
* mi-malloc should help windows version a little, because VC6 msvcrt allocator is far from being good
* it is now possible to manage map marks
    'n' key will hightlight next map mark.
    'shift+c' key will remove either the highlighted mark, or all marks if nothing was highlighted.
    i changed 'c' to 'shift+c', so you won't accidentally delete a mark.
    if you deleted a highlighted mark, and then pressed 'm' without pressing 'n', deleted mark slot will be reused.
* automap marks now stored in saved games (loaded marks will not replace user marks)
* it is now possible to render textured automap (toggle with 't' when automap is active)
* added automap options menu
* better sound management (do not immediately free played sound, because memory is cheap, and constant sound reloading is bad)
* added autocompletion to "map" console command
* implemented action special 154 (LNSPEC_TeleportNoStop)
* fixed bug in decal saving (not critical, just some visual glitches)
* Chainsaw will not alert monsters if no monster was hit
* use OS login name as default player name
* refiring weapon has less chance for headshots or criticals
* restored the sound made by doors crushing dead bodies (spat)
* legacy/3dge 3d floor translation was completely broken (the engine did it wrong, and in the wrong place)
* automap now show keys in seen subsectors (can be switched off; sorry, i can never remember where that stupid key was)
* engine will automatically select node builder (it usually knows better which one to select)
* fixed MAJOR AJBSP flaw: node coords should be floating to correctly process UDMF maps (this is not Andrew's flaw, it was my fault)
* fixed major bug in x86_64 VC dictionary implementation (GREAT thanks to id0 for spotting it, and for help!)
* moved saves to subdirectories of the main savegame dir (old saves will still load, so it is transparent for you)
* oops! shaders for non-reverse-z mode were completely broken!
* added some Doom Legacy line specials (not all of them yet, tho), tnx to Mr.Rocket for test map
* added support for `LOF_NOJUMP` flag in `A_LookEx()` decorate action
* items placed on 3d floors should not sink into those 3d floors anymore (that could happen in some rare cases)
* implemented missing arguments handling for `A_Explode()` decorate action
* added handling of missing `JLOSF_XXX` flags to decorate
* FS statusbar will show berserk pack when player has berserk powerup
* added simple GZDoom MODELDEF parser (disable with "-no-modeldef" CLI arg)
* implemented UDMF floor/ceiling light levels (doesn't affect sprite lighting yet; not interpolated)
* implemented UDMF floor/ceiling glow (doesn't affect sprite lighting yet)
* and some other UDMF lighting properties
 

Share this post


Link to post
Just now, ketmar said:

* Chainsaw will not alert monsters if no monster was hit

Finally, my dream of playing the map's music with the chainsaw without getting attacked by everything can be finally realized! Thanks, ketmar!

Share this post


Link to post

I sincerely hope that the chainsaw thing is a user option - this is the kind of thing that may break mods on occasion.

 

Share this post


Link to post
Posted (edited)

neither it, nor fist stealth kicks punches. built-in chainsaw and fist are using new decorate codepoint (but states are the same). if some mod redefines a chainsaw, it will work as a normal chainsaw. and if mod doesn't, then i assume that chainsaw alert mechanics is not relevant. i.e. it won't break custom weapons.

 

p.s.: if somebody will report a broken mod, i'll make it optional. but for now, i simply forgot. meh, until people will start complain, i'll consider it flawless. ;-)

Edited by ketmar

Share this post


Link to post

Knowing this community, people *WILL* start complaining about such "gratuitous" changes. ZDoom got criticized for far lesser "offenses".

 

Share this post


Link to post
Posted (edited)

and i will politely ignore all complaints of "i don't like it this way" kind. i have a clear vision for k8vavoom project, and i (most of the time) won't change something only because some people don't like it. at least not if it is something that goes against my vision.

 

k8vavoom already has gameplay changes (slightly different physics, slightly altered monster AI, and so on). there are alot of other sourceports out there for thouse who don't like the way i'm doing things. tbh, that was one of the reasons i didn't joined GZDoom developement: i like to make changes, and experiment with new ideas. Vavoom is a "minor" sourceport, so i can do almost anything i want without killing some mod people still want to play. the only vavoom-specific mod (TC, actually) i know is Scattered Evil, and i already talked with RambOrc (we have some plans, but don't have enough time, as usual ;-).

Share this post


Link to post
Posted (edited)

so, i looked at various source code, and finally understood (i think) how to use FluidSynth. so from the next build, there will be two midi backends. fluidsynth backend is still experimental, though -- i implemented just enough midi parsing to play internally converted MUS files, and will prolly have to add more midi command processing. but it seems to work.

 

p.s.: of course, it won't help default windows music even a little, because fluid cannot load DLS fonts. v2 can, if there is a library, but using it is out of question. and fluidsynth-lite from doom64ex project cannot.

 

btw, i immediately found a bug in fluidsynth-lite. had to workaround it. sorry, kaiser, i haven't enough energy to properly debug it.

 

p.p.s.: fluidsynth documentation has all kind of examples except this vital one. sigh.

Share this post


Link to post

@ketmar: A random suggestion:

 

I've read quite a few comments you've made, where you state you're "not good at graphics". But, I look at your screenshots, and think "Huh? There's some awesome graphics going on there!"

 

I suppose you're being modest, and this is NOT a criticism of you or your code. If you're really not as comfortable with graphics as you'd like to be, I suggest:

1. Make a fork of your code, pick one awesome map or two, and start adding a bunch of debugging code, and a bunch of new graphics techniques. Take a break from the standard stuff, and focus on graphics for some time, until you become fluent in all the possible techniques.

 

2. If you really have some time, start a new project. Bring in some map loading code, and some preliminary graphics primitives. This is a radical move, but the benefit is that you have a small code-set, and you can try just about anything.

 

Your source port specializes in beautiful, advanced rendering, and you can obviously code. Yet you're always saying "I hate graphics code..." Are you kidding? If so, no problem. Otherwise, maybe it's time to take the time.

 

Actually, I'm projecting here: This is something I've been wanting to do for a long time, but I have no time to invest right now. Just a suggestion.

 

Share this post


Link to post
Posted (edited)

@kb1 no, i'm not kidding, i really hate doing gfx. for me, this is most boring part of engine developement. and sadly, the part that impresses people most. almost nobody will be impressed by smart VM design, or JIT compiler ("ah, it becomes faster. ok then, does it mean that we'll get a fancier pictures?" ;-).

 

of course, i have enough general programming expirience to learn basics of GPU programming. sure, i can master it if i invest enough efforts into it. but it is simply boring for me. it is like programming in assembler: i enjoyed it when i was younger, and now i think that it is a waste of time. i still can write decent asm code, but why?

 

what i really want to do is VavoomC improvements. rewriting VM to register-based will immediately give a x2-x5 speed boost. adding JIT compiler on top of it will speed it up even more. i also want to add various optimising stages, like general SSA optimiser, method devirtualisation, and others. i also have some plans on extending the language. now, this is what i really love to do. but i have to move it lower and lower in TODO list because of rendering.

 

no, really, i think that computer graphics is really boring area. there was nothing new in decades, just the same old concepts, and hardware hacks. where are my fully dynamic voxel worlds with sophisticated physics simulation, everything in real-time?! ;-)

 

besides all that, i don't believe that doom engines need any fancy gfx. like, i know how to implement various "advanced gfx tech" (all those buzzwords like displacement maps, GI, hubba-bubba-dubba-lighting-models and so on), i just don't see any reasons to do that in doom sourceport. i don't even believe that doom sourceport need to support hires textures (that's why it is semi-broken in k8vavoom for ages -- i simply don't have enough motivation to fix it).

 

tl;dr: CG is not someting i am interested in. i still think that Rogue had enough gfx to provide great gameplay. ;-)

 

p.s.: i don't even want to code something as easy as bloom postprocessing effect. because it means more GPU coding. no, please, no!

Share this post


Link to post
48 minutes ago, ketmar said:

what i really want to do is VavoomC improvements. rewriting VM to register-based will immediately give a x2-x5 speed boost. adding JIT compiler on top of it will speed it up even more. i also want to add various optimising stages, like general SSA optimiser, method devirtualisation, and others. i also have some plans on extending the language. now, this is what i really love to do. but i have to move it lower and lower in TODO list because of rendering. 

 

Are you sure about the x2-x5 boost? I have benchmarked the GZDoom VM to get an idea how hard the speed hit of scripting code is, and the factor was a rough 10, which is nearly the same I got when I benchmarked the ACS stack machine a few years ago. The biggest problem with any kind of bytecode interpreter is always the invisible code the compiler produces, so in the end if'd really come down to "the less VM instructions executed, the faster". From that I'd say that a x1.5 speed boost would sound reasonable, but on the other hand I do not know if VavoomC got some other inefficiencies that affect its speed.

 

Adding the JIT compiler brought a 3-5x speed improvement in code that runs mostly in scripts, but considering that even most scripted code performs a lot of engine calls the actual improvement is a lot less, ranging from being negligible (most of the time) to a modest 1.5-2x improvement.

 

48 minutes ago, ketmar said:

no, really, i think that computer graphics is really boring area. there was nothing new in decades, just the same old concepts, and hardware hacks.

 

Do you really think so? While there may have been no new concepts, what has changed dramatically is the accessibility of those concepts. Before programmable shading it was plain and simply impossible to do advanced rendering effects in real time, now we get to run complex code on a per-pixel basis, and with hardware-based ray tracing the next big step forward to bring new concepts into the mainstream.

 

 

48 minutes ago, ketmar said:

where are my fully dynamic voxel worlds with sophisticated physics simulation, everything in real-time?! ;-)

 

Let's just say they are a few game generations in the future from Doom. ;)

It's not that these things are not doable, but that the Doom engine and the need to preserve its essence do not make it easy or even feasible to change the broken physics model it employs.

 

If that's what you want to work on, wouldn't be something more advanced like the Quake 2 or Quake 3 engines more fitting? Doing this in Doom sounds like trying to fit a square peg into a round hole. You'd be constantly running into walls that are a lot higher and a lot thicker than the graphical issues that happen.

 

 

48 minutes ago, ketmar said:

besides all that, i don't believe that doom engines need any fancy gfx. like, i know how to implement various "advanced gfx tech" (all those buzzwords like displacement maps, GI, hubba-bubba-dubba-lighting-models and so on), i just don't see any reasons to do that in doom sourceport. i don't even believe that doom sourceport need to support hires textures (that's why it is semi-broken in k8vavoom for ages -- i simply don't have enough motivation to fix it).

 

To each their own, I guess. I see it differently. For me, the gameplay mechanics are the fundamental skeleton of the engine. They define how the game handles and how the player interacts with the virtual world, so it's the area for everything that wants to present the original game where the most conservatism is needed.

 

Enhancing the graphics is another thing, because by itself it doesn't change the underlying game - all of the most graphically advanced source ports still show something that looks unmistakably like Doom, but change the physics and it will alter how the game handles. Even ZDoom got criticized for that quite a lot, even though most of the changes in physics were quite minor mostly, but for some players who are very sensitive toward gameplay mechanics, even that was too much (you know, stuff like "Hey, where's my wallrunning, I can't play this game at such a snail's pace...")

 

48 minutes ago, ketmar said:

 

tl;dr: CG is not someting i am interested in. i still think that Rogue had enough gfx to provide great gameplay. ;-)

 

p.s.: i don't even want to code something as easy as bloom postprocessing effect. because it means more GPU coding. no, please, no!

 

It's great when you find someone else who likes doing this stuff. Otherwise GZDoom wouldn't have it either. TBH, most of the enhanced graphics stuff is features I never use myself. The only genuine value all this postprocessing brought to me personally is that it allowed to clean up the render backend quite considerably and that it laid the foundation for implementing a Vulkan renderer.

 

Share this post


Link to post
Posted (edited)
27 minutes ago, Graf Zahl said:

Are you sure about the x2-x5 boost?

this is rough estimate from my expirience with stack-based and register-based VMs. usually, register-based one outperforms stack-based one around this numbers. it is less noticeable when a script is mostly calling some native methods, but in k8vavoom, almost all the game code is written in VavoomC, and it does alot of math. replacing series of "push, push, math, store" with simply 3-op "math" should give a huge speed boost due to less dispatching.

 

27 minutes ago, Graf Zahl said:

considering that even most scripted code performs a lot of engine calls

in k8vavoom, we can actually say that the game is almost written in VavoomC, not scripted. and i want to move even more things to VC side, but i need a fast VM for that. basically, C++ side only does rendering, and some coldet code (not that much, tho). and i want to move all coldet to script side too -- there are no reasons i can't do that, besides speed.

 

27 minutes ago, Graf Zahl said:

Do you really think so? While there may have been no new concepts, what has changed dramatically is the accessibility of those concepts.

yeah. "twenty years ago we couldn't do it in real time, but now we have enough horse power to crunch it." nothing new, just more powerful hardware that can do more and more old things in real-time.

 

27 minutes ago, Graf Zahl said:

If that's what you want to work on, wouldn't be something more advanced like the Quake 2 or Quake 3 engines more fitting?

sadly, we don't have enough hardware power to do what i want to do yet. and no current engine is fitting at all. maybe Atomontage, but i don't know its internals, and it is closed source anyway.

 

there is another problem: having a game for your engine. with doom, i have almost infinite stream of wads to play. if i don't have a good game for my engine, i don't have any motivation to develop it. yes, chicken-and-egg problem. ;-)

 

27 minutes ago, Graf Zahl said:

The only genuine value all this postprocessing brought to me personally is that it allowed to clean up the render backend quite considerably

yeah, that is what i wanted to do for a long time too. vavoom rendering code is not that bad, but it definitely can be made better. i am slowly working on it, but... the engine is HUGE. tbh, it maybe as huge as GZDoom in terms of features and design (by numbers and concepts, not by one-to-one correspondence, of course ;-), and i just don't have enough time to do everything i want. and i am working on k8vavoom almost on a full-time, if we count my hours spent on it.

 

still, there are physical human limits too -- i cannot code 12+ hours a day, like i could 10 or 20 years ago. sigh.

Share this post


Link to post
11 minutes ago, ketmar said:

in k8vavoom, we can actually say that the game is almost written in VavoomC, not scripted. and i want to move even more things to VC side, but i need a fast VM for that. basically, C++ side only does rendering, and some coldet code (not that much, tho). and i want to move all coldet to script side too -- there are no reasons i can't do that, besides speed. 

 

Speed is the most important reason for sure, and the main one I haven't ported more code than I already did, but there's another one:

It is still a lot easier to debug native code - the one thing I absolutely do not want to do is write a script debugger.

 

 

11 minutes ago, ketmar said:

yeah. "twenty years ago we couldn't do it in real time, but now we have enough horse power to crunch it." nothing new, just more powerful hardware that can do more and more old things in real-time. 

 

And yet, we still haven't reached the stage where photorealistic rendering is possible. Then again, do we need that...?

 

 

11 minutes ago, ketmar said:

still, there are physical human limits too -- i cannot code 12+ hours a day, like i could 10 or 20 years ago. sigh.

 

Heh, I look at it differently - if I could go visit my younger self, I'd tell him to sit less in front of a computer and enjoy other things instead.

It's more like I do not WANT to spend so much time in front of a computer anymore, not that I CAN'T.

 

Share this post


Link to post
15 minutes ago, Graf Zahl said:

It is still a lot easier to debug native code - the one thing I absolutely do not want to do is write a script debugger.

ah, that is not a problem for me at all: i am using `printf()` as my debugger for decades. so it doesn't matter where to put those printfs. ;-)

no, really, the only use of gdb for me is to get a backtrace on segfault. and VavoomC VM already gives me backtraces (that was almost the first thing i implemented).

 

16 minutes ago, Graf Zahl said:

And yet, we still haven't reached the stage where photorealistic rendering is possible. Then again, do we need that...?

this is a good question. more realistic art require more money and time, and not always better than simple art. i believe that doom scene is still alive exactly because of doom limits and simplistic graphics. it is hard to impress people with something built on modern engines -- AAA studios have more resources. but with doom, it is still possible to build something great in your free time.

 

20 minutes ago, Graf Zahl said:

It's more like I do not WANT to spend so much time in front of a computer anymore, not that I CAN'T.

i have no life anyway. ;-) no, i am not complaining, i'm ok with it. i have friends and such, but i'm ok seeing them once in a month or so, and spend my other days at a computer.

Share this post


Link to post
Posted (edited)
2 hours ago, ketmar said:

@kb1 no, i'm not kidding, i really hate doing gfx. for me, this is most boring part of engine developement. and sadly, the part that impresses people most. almost nobody will be impressed by smart VM design, or JIT compiler ("ah, it becomes faster. ok then, does it mean that we'll get a fancier pictures?" ;-).

Oh, I misunderstood. I didn't realize that you found it boring - I would have never guessed that. Good enough :)

 

Quote

what i really want to do is VavoomC improvements. rewriting VM to register-based will immediately give a x2-x5 speed boost. adding JIT compiler on top of it will speed it up even more. i also want to add various optimising stages, like general SSA optimiser, method devirtualisation, and others. i also have some plans on extending the language. now, this is what i really love to do. but i have to move it lower and lower in TODO list because of rendering.

 

Ok, I have a different idea: Have you ever considered writing your own stand-alone language (yes, maybe with a *moderate* GUI engine that let's you present windows/forms)? That sounds like it could be a lot of fun.

 

To do it right, you'd need a nice code editor window (which are a pain-in-the-ass to build, but easy enough to find some decent code), and maybe some nice cross-platform GUI code (windows, textboxes, checkboxes, etc.)

 

It could always be dumped back into the game later, and you'd have a stand-alone version for building programs. It's something I've been toying around with for years now.

 

1 hour ago, Graf Zahl said:

Do you really think so? While there may have been no new concepts, what has changed dramatically is the accessibility of those concepts. Before programmable shading it was plain and simply impossible to do advanced rendering effects in real time, now we get to run complex code on a per-pixel basis, and with hardware-based ray tracing the next big step forward to bring new concepts into the mainstream.

Personally, I love graphics. It is, after all, the main output to the user, if you discount sound and printer.

 

49 minutes ago, ketmar said:

still, there are physical human limits too -- i cannot code 12+ hours a day, like i could 10 or 20 years ago. sigh.

I can't either, sadly. We're starting to show our ages here... :)

 

32 minutes ago, Graf Zahl said:

Speed is the most important reason for sure, and the main one I haven't ported more code than I already did, but there's another one:

It is still a lot easier to debug native code - the one thing I absolutely do not want to do is write a script debugger.

I hate to admit that I get way too much mileage out of littering my code with:

#ifdef DEBUG

  WriteMsgToFile "1"

  ...

  WriteMsgToFile "2386"

 

:)  EDIT: Heh! ketmar crossed-posted "printf()"!! We're on the same wavelength!

 

Quote

Heh, I look at it differently - if I could go visit my younger self, I'd tell him to sit less in front of a computer and enjoy other things instead.

It's more like I do not WANT to spend so much time in front of a computer anymore, not that I CAN'T.

Amen, brother!

 

EDIT: @ketmar: You do have a life, that many people would be jealous of. Me, for one. I wish I had the time to spend coding for my personal projects. And, your friends can spend their time playing your game ;)

 

Share this post


Link to post
7 minutes ago, ketmar said:

ah, that is not a problem for me at all: i am using `printf()` as my debugger for decades. so it doesn't matter where to put those printfs. ;-)

no, really, the only use of gdb for me is to get a backtrace on segfault. and VavoomC VM already gives me backtraces (that was almost the first thing i implemented).

 

This is actually something I never understood. Having a GUI debugger is such a helpful thing when analyzing code, I couldn't work without it. If that was the way of things I'd have chosen a different profession, actually.

 

Surely, littering code with printf is a valid analyzing technique, but sometimes you need to break at a certain point and analyze the entire state to see what's going on.

 

7 minutes ago, ketmar said:

i have no life anyway. ;-) no, i am not complaining, i'm ok with it. i have friends and such, but i'm ok seeing them once in a month or so, and spend my other days at a computer.

 

It stops being fun when it starts affecting your health. Those endless night sessions were not without consequences, unfortunately.

Share this post


Link to post
Posted (edited)
11 minutes ago, kb1 said:

Have you ever considered writing your own stand-alone language (yes, maybe with a *moderate* GUI engine that let's you present windows/forms)?

i did it alot of times, with different kinds of languages (smalltalk-like, forth-like, c/pascal-like, duck-typed-like). i am Teh Compiler Guy after all. ;-)

 

11 minutes ago, kb1 said:

To do it right, you'd need a nice code editor window (which are a pain-in-the-ass to build, but easy enough to find some decent code)

heh, i am already writing all my code with my own code editor. which has separate editor and highlighting backend, and rendering frontend. it was used in several of my projects (including email client ;-).

 

11 minutes ago, kb1 said:

and you'd have a stand-alone version for building programs

take a look at Spelunky remake here. it is done with standalone VavoomC runner, there is no other k8vavoom code in it.* actually, i am using vccrun to develop various prototypes. for example, new collision detection system -- it is completely written in VavoomC, including barebones BSP-based renderer. ;-)

 

i also have a flexible GUI system with flexbox-based layouting engine, written in VavoomC too. it will eventually be put into k8vavoom to use in various in-engine tools.

 

tbh, most of the first hidden year of k8vavoom developement was spent on improving VavoomC compiler. it is far more advanced than VC compiler from original Vavoom now.

 

 

* in Spelunky remake, *everything* except rendering the quads is done in VavoomC. i.e. vccrun has some OpenGL and sound API accessible, but everything else is VC code. including map rendering, collision detection, and other things.

Share this post


Link to post
7 minutes ago, Graf Zahl said:

This is actually something I never understood. Having a GUI debugger is such a helpful thing when analyzing code, I couldn't work without it. If that was the way of things I'd have chosen a different profession, actually.

 

Surely, littering code with printf is a valid analyzing technique, but sometimes you need to break at a certain point and analyze the entire state to see what's going on.

i used to use interactive debuggers in the past. but as the time passes, i realised that i am simply doing mindless breakpoint/singlestepping in debugger instead of stopping it all, and trying to analyse the problem. once i realised that, i found that `printf()` is more than enough. most of the time i need to think a little, and then i only have several interesting values to print to narrow the problem.

 

i am not trying to say that using interactive debugger is wrong, no. i only mean that i don't need it anymore, and can debug the code without it faster.

 

besides, there is interactive in-app cosole for me. most of my apps has such console in them, with wide variety of accessible commands and variables. actually, i am building my apps around the console engine. ;-)

 

11 minutes ago, Graf Zahl said:

It stops being fun when it starts affecting your health. Those endless night sessions were not without consequences, unfortunately.

yeah, that is the problem. i want iddqd irl! ;-)

Share this post


Link to post

@ketmar: Again, we're on the same wavelength! Awesome!

 

20 hours ago, Graf Zahl said:

This is actually something I never understood. Having a GUI debugger is such a helpful thing when analyzing code, I couldn't work without it. If that was the way of things I'd have chosen a different profession, actually.

 

Surely, littering code with printf is a valid analyzing technique, but sometimes you need to break at a certain point and analyze the entire state to see what's going on.

Well, you were hoping to not have to build a big script debugger. printf() or WriteMsgToFile() is the quick and dirty alternative. And, there's always that pathological case where, despite having a nice GUI debugger, you still have to do something custom. For example, when iteration 5555 crashes based on something that happened on iteration 4444. It's not practical to single-step 5000 times. But, if you can dump a few values to a file, you can see patterns in the data that you just don't get to see anywhere else. So, it has its uses.

 

You're right - at some point, sloppy printf stuff becomes more tedious than taking the time to build something nice. I say avoid it as long as possible. But, if you start spending all your time manually analyzing scripts, it may become practical to bite the bullet. One things for sure: Once you have a nice debugger, you'll never want to go back :)

 

20 hours ago, Graf Zahl said:

It stops being fun when it starts affecting your health. Those endless night sessions were not without consequences, unfortunately.

Yep, physical, mental, emotional, spiritual. I've been accused of laziness, sitting around in front of the computer in the A/C. I challenge those people doing physical labor to step into my shoes for a few months. When code problems start to invade your dreams, that's when health problems can occur. Many people have the luxury of leaving their work problems at work, but not programmers. Programming is a 24/7 job.

Share this post


Link to post
3 hours ago, kb1 said:

I've been accused of laziness, sitting around in front of the computer in the A/C. I challenge those people doing physical labor to step into my shoes for a few months. When code problems start to invade your dreams, that's when health problems can occur.

yeah. also, actually typing the code is the latest (and sometimes most tedious ;-) phase of programming. if you see someone sitting in front of his computer and frantically typing all the day, there is almost 100% guarantee that they're not a good programmer. most of the time good programmers spent goes into thinking about things. building things is easy. building good things is hard. some of my most productive programming days had zero code commits at all. ;-)

Share this post


Link to post
2 hours ago, ketmar said:

yeah. also, actually typing the code is the latest (and sometimes most tedious ;-) phase of programming. if you see someone sitting in front of his computer and frantically typing all the day, there is almost 100% guarantee that they're not a good programmer. most of the time good programmers spent goes into thinking about things. building things is easy. building good things is hard. some of my most productive programming days had zero code commits at all. ;-) 

 

 

This is so true but tell that to the project managers. Sometimes I just need to mentally drift off, which results in visiting random sites on the internet just to get a distraction. Few people understand that this is a necessary part of the whole process.

 

All those 'modern' development ideas like "agile" and such seem to have been designed to burn out the programmers' creativity.

 

Share this post


Link to post

Create a metric to measure a programmer's performance, and you get a new way to game that metric:

 

  • Number of lines of code written: code lines become smaller and smaller
  • Number of comments added: Each line receives it's own comment
  • Number of bugs fixed: Your colleague creates bugs on Monday, you fix bugs on Monday. On Tuesday, reverse roles!

The only way to measure productivity is to spend time with the employee, and get to know him or her. Then you can tell if they are real, or full of BS. Bean counter mentality just doesn't cut it. And, yes, distractions and procrastinations are necessary to give your mind a rest, and let your subconscious work out the details.

 

Basically, you give me money, and I write you code - end of transaction. Also, it'll be done When It's Done, period. Put that in your spreadsheet :)

Share this post


Link to post
24 minutes ago, kb1 said:

 Also, it'll be done When It's Done, period. Put that in your spreadsheet :)

 

Tell that to the people making the schedules. The one universal constant is that these schedules always fail and the pressure is on the developers then.

 

 

Share this post


Link to post
Posted (edited)
14 minutes ago, Graf Zahl said:

Tell that to the people making the schedules. The one universal constant is that these schedules always fail and the pressure is on the developers then.

and even if we'll giving managers some estimates, it usually ends like: "three monthes? ok, i hear". "boss, we can do it in two weeks! sure, we can!" "good news, everyone! we have one week to do it!"

 

p.s.: and some ontopic (i like our chatting, no need to cut it off! ;-): i finally was forced to write a midi (smf) parser to feed fluidsynth. now, as i have it, i will prolly look at least into wildmidi and nukedopl, because why not? i have very simple mus/midi player with nukedopl in my another project, so it shouldn't be a big problem. (the famous last words, yeah.)

Edited by ketmar

Share this post


Link to post
1 hour ago, ketmar said:

 (the famous last words, yeah.)

 

MIDI playback isn't "not a big problem.", especially when you have to hook up with the idiocies some external players do. I spent 6 weeks getting Timidity++ to a state where I could drive it with an external event processing loop and get the waveform data returned, instead of having it sent to a badly implemented player.

 

If you want a good player, check it out, it's definitely better than WildMidi and has been stripped down to the needs of an external sequencer.

 

Share this post


Link to post
Posted (edited)
19 minutes ago, Graf Zahl said:

If you want a good player, check it out, it's definitely better than WildMidi and has been stripped down to the needs of an external sequencer.

tnank you, i will definitely look at what GZDoom has to offer there. for now i will prolly add nukedopl for those who like vintage OPL3 sound, but later i may add other backends. because why not? ;-)

 

p.s.: i used fluidsynth-lite from kaiser, so k8vavoom can be built without system fluid installed. it is not the most recent version, but meh. and there is an option to use system fluid library. for now, i am happy, and people on windows will get better music.

Share this post


Link to post
Posted (edited)

@Graf Zahl by the way. in GZDoom mus->midi converter, why it does this:

		case MUS_NOTEOFF:
			status |= MIDI_NOTEON;
			mid1 = t;
			mid2 = 0;
			break;

shouldn't it be "MIDI_NOTEOFF"? is it to emulate some DMX bug, or just a typo?

 

p.s.: i see that is simply plays a note with zero volume velocity (whatever that means). this is prolly how DMX did it, yes?

Edited by ketmar

Share this post


Link to post

Sorry, I have no idea. This code was written by Randi and I cannot say what it's supposed to accomplish.

 

Share this post


Link to post
Posted (edited)
25 minutes ago, Graf Zahl said:

Sorry, I have no idea. This code was written by Randi and I cannot say what it's supposed to accomplish.

it looks like a genuine copypasta bug then. i bet this came from some ancient MUS2MIDI utility. even if it goes to emulate some obscure DMX bug, replacing it with "MIDI_NOTEOFF" should be The Right Way To Do It. and maybe raise velocity a little (to 32, for example). it (velocity) has no effect on FluidSynth (and i doubt that it has any effect in any other midi synth), but if anything, it should produce slightly nicer sound.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×