next »

[Scifa]

Should have done object pooling

[CodeLobe]

Yay! The machine "wakes on LAN", boots up with a VERY simple network stack and the ability to load & execute data from the network.

Quick! Send it the bootstrap code packets to get the OS online!

Nope.  Every blasted time some other device hits it up, the machine trys to execute some packet of random network traffic as if it were root level OS boot code. (pre-production, nosec yet).  Win desktops are constantly pinging it with device queries as soon as it gets an IP address from the DHCP server.  I could direct connect to isolate, but where's the sense of adventure in that?

Indeed, this is why "ports" were invented...  So, I quickly implement simple "ignore anything but port, uh... 45678, yeah."  Nope. Still being gorked soon as it boots, WTF?

waste two hours trying to figure it out.

Scratch my head hard... Finally resort to Wireshark.  Packet sniffing reveals a server is still trying to complete a print job, polling for any IP with that port open.  That... server... why is a caching server trying to print anything?  Is the system compromised?!  Soon realize port 45678 is what i set CUPS (Common UNIX Print System) print spool servers to use once upon a time before I remembered 49xxx is proper dynamic CUPS port range standard.  The print job is from way back when I set up the server and tried to print out its config to update the intranet reference manual.

Yes, I had "randomly" picked 45678 back then too for CUPS...  It all comes flooding back to me now.  Initial failure to print caused me to look up the proper CUPS port numbers and change the configs of the spools in a time when this place was far less dusty.  And I never went back to the sever because it wasn't broke, and doesn't need fixing.

...and that server has been trying to complete the print job ever since!  Screw you Past Me!  You sloppy bastard!  This is all your fault for not completing the paper work to finish off that job!

Why not just use "pixi boot" or other netboot standard?  There is an answer, but that is a story for another time. 

Thus concludes another chapter of "Adventures in Alternative OS Development".

[Crimsontide]

Oh man... that's horrible luck.

[InfiniteStateMachine]

Yay! The machine "wakes on LAN", boots up with a VERY simple network stack and the ability to load & execute data from the network.

Quick! Send it the bootstrap code packets to get the OS online!

Nope.  Every blasted time some other device hits it up, the machine trys to execute some packet of random network traffic as if it were root level OS boot code. (pre-production, nosec yet).  Win desktops are constantly pinging it with device queries as soon as it gets an IP address from the DHCP server.  I could direct connect to isolate, but where's the sense of adventure in that?

Indeed, this is why "ports" were invented...  So, I quickly implement simple "ignore anything but port, uh... 45678, yeah."  Nope. Still being gorked soon as it boots, WTF?

waste two hours trying to figure it out.

Scratch my head hard... Finally resort to Wireshark.  Packet sniffing reveals a server is still trying to complete a print job, polling for any IP with that port open.  That... server... why is a caching server trying to print anything?  Is the system compromised?!  Soon realize port 45678 is what i set CUPS (Common UNIX Print System) print spool servers to use once upon a time before I remembered 49xxx is proper dynamic CUPS port range standard.  The print job is from way back when I set up the server and tried to print out its config to update the intranet reference manual.

Yes, I had "randomly" picked 45678 back then too for CUPS...  It all comes flooding back to me now.  Initial failure to print caused me to look up the proper CUPS port numbers and change the configs of the spools in a time when this place was far less dusty.  And I never went back to the sever because it wasn't broke, and doesn't need fixing.

...and that server has been trying to complete the print job ever since!  Screw you Past Me!  You sloppy bastard!  This is all your fault for not completing the paper work to finish off that job!

Why not just use "pixi boot" or other netboot standard?  There is an answer, but that is a story for another time. 

Thus concludes another chapter of "Adventures in Alternative OS Development".

That was an amazing story. I look forward to the next chapter

[ferreiradaselva]

Single header file to define all structures of my game was getting to bloated, not here I am suffering to move everything to their own header, but worse, having to organize the project structure to work with opaque pointers as consequence.

Also, I hate naming things. You have no idea how many times I changed the structure name from "gameentry" to "entrypoint" and from "entrypoint" to "gameentry".

edit:

I'm really thinking about going back to "one massive header, multiple source files". Working with one opaque structure is fine, but multiple is a pain, especially if you are obsessed with keeping all your game structure as a static declaration. You will find yourself trying to solve circular inclusion inside circular inclusion inside circular inclusion.

edit 2:

Went back to "single header, multiple sources" scheme. At least some of the refactoring I made could be used.

edit 3:

I woke up with a solution. Back to multiple headers. Nothing like a good night of sleep.

[Ordnas]

I would avoid "single header, multiple sources" because it generally increases compile times and the complexity of static initialization.

[CodeLobe]

I would agree to avoid single headers...

EXCEPT! When using "single source optimization" (usually as a last step for the release build, and only on a system with shit tons of [usually virtual] RAM, i.e., distributed compute).

The "release" build is then created via the concatenation of as many header files as possible, followed by the concatenation of as many source files as possible, e.g., One .h and One .c would be optimal (but usually not possible unless you code EVERYTHING yourself and plan for 1-src-opt).

The cost of planning to do this can be moderately high unless built into your build suite, but the benefit is that it typically squeezes down the resultant program's memory footprint and wins a percent or few faster execution times.  On PC you're typically not up against such a hard wall that such figures would be worth it, but on embedded systems, consoles, mobiles, etc. then it might be worth it if you just need a few (hundred) more KiB for a new feature to fit, or to squeeze in a few more physics calculations within a render frame.

<grumble>
There once was a time when I'd rewrite almost the whole damn project in assembly [#ifdefs galore] once I had figured out how the systems were supposed to work in a higher level language (and they wouldn't be changing anymore).  Nowadays I still write tons better code than any compiler can generate, but rarely take the time.  Don't let the marketing hype fool you: Disassemble some G++, LLVM/Clang or MSVC binaries and see the horrid junk they produce yourself; Software can NOT even come close to writing better ASM than a skilled human; CPUs are just very fast now.  ASM is crap to maintain unless your platform is stable as hell (hint: x86 is rock steady; Most desktop systems can still boot up in 16bit real mode, JUST IN CASE you're booting MS DOS (or DR-DOS) on your brand new 64bit chipset...)
</grumble>

TL;DR: If you need a little extra umpf and don't feel like hand optimizing some things in ASM, then a single .h / .c source optimization may be just the ticket.

[Crimsontide]

Its not really about whether or not you have 1 or multiple headers, its about dependencies.  If you spread 1 header across 10, but still have to (directly or indirectly) include all 10 whenever you use any of it, you didn't save any time when it comes to compilation.

Rule of thumb, if they are independent, use separate headers; but otherwise it doesn't matter.

[Daid]

TL;DR: If you need a little extra umpf and don't feel like hand optimizing some things in ASM, then a single .h / .c source optimization may be just the ticket.

Is that still valid with LTO? https://gcc.gnu.org/wiki/LinkTimeOptimization


I have done "unitless" code, where just all the code is in header files, but still spread along a whole bunch of different files, but compiled from a single main source file. Mainly just me being lazy.

[CodeLobe]

TL;DR: If you need a little extra umpf and don't feel like hand optimizing some things in ASM, then a single .h / .c source optimization may be just the ticket.

Is that still valid with LTO? https://gcc.gnu.org/wiki/LinkTimeOptimization

Yep.  Single source leverages the compile time optimizer and may be able to perform optimizations that link time compilation doesn't  do (but COULD? do, in theory).  Theoretically GCC's GIMPLE internal representation COULD allow compilers (or linkers, or whatever) to reconstruct the abstract syntax tree, however note that during the transform from the higher level language we have lost some meta information which could be usable as optimization hints / patterns during compile time optimization.  Clang/LLVM's AST also theoretically allows greater optimization potential but the compiler itself isn't as mature.

Consider the simple case where two (or more) compilation units have some partial similarities in code which can be condensed, but where each one compiled independently resolves into a different, less optimal, batch of code.  During link time optimization the linker might not be able to identify the pattern.  Link time is usually fitting together blocks of code, eliminating obviously repetitious chunks if possible, and of course resolving symbols, whereas compile time optimizations are far more in-depth and rigorous.

[gimymblert]

I'm finally reaching the end part of my planet generation r&d about inflated sphere coverage ...

Nothing is working as intended and new perplexing problem are happening, expect more grumpy in the future with nice image of despair.

                                     
                                                       

[gimymblert]

Well turns out most of the problem I had was about:

pos.y = pos.x + stuff; 
pos.x = pos.y + stuff; 

and
tilestuff[ax,ay] in someplace 
tilestuff[ay,ax] in others 
why? I don't even get how this is even possible 

so I wasted MONTH on STUPID STUFF ARGHHHHHHHHHHHH 

 

[qMopey]

o_o

[quantumpotato]

[ProgramGamer]

Watching this video for the second time at the moment. It's a very interesting concept to standardize the hardware interface to common devices such as network cards and USB ports.

Who's up to make a TigsOS

[gimymblert]

Who's up to make a Tigsauce

I see what you did here 

[ProgramGamer]

that was in fact not an intentional pun, but I'll take it anyway lol

[Mannapi]

Spent a good part of yesterday trying to find out why my UE4 project did not compile only to find there was a missing semicolon in a line above an Unreal macro, causing the build system to freak out and point in all the wrong directions.

[quantumpotato]

Watching this video for the second time at the moment. It's a very interesting concept to standardize the hardware interface to common devices such as network cards and USB ports.

Who's up to make a TigsOS

Paging voidSkipper

[gimymblert]

convex (quick)hull: conflict list and horizon are way too complex for me