The last two days and nights I've spent bilding on Lego guns. Not the ideas I had but rather improve of the model lying around for more than a year. The one I haven't even made pictures of and it's nearing completition in many ways. One thing I did was a minor bullet improvement which will allow smoot chambering and cartridge collision/sliding in later models. Looks sorta bad-ass right now. The second is a stock for the yet not showcased double-barrel rifle. I think it's time the finally give it a name: cartridge rifle mark III. Why mark III ? Mark I was the first design ever with a giant cartridge, one-shot and break-action. Mark II I never posted about cause it never felt good or event finished. It was flawed and too crude in construction and design. Mark III however didn't see any real finish for more than a year and the improvements over mark II are astronomical (including a final stock and bullet holders). However, it's still only the next level in a long line of improvements. It seems that this is my ultimate, personal quest of endless possible improvement. The thing everything should need in his life. I'm interested in how mark IV may look some day. I can only guess that it'll take more than a year to even know anything about. On the other side I feel bad for not following my plans to continue my bachelor work. I wanted the implementation part done this year (== what I achieved) but also the functionality and improvement tests. Emotionally I felt that I need to work and finish this gun to feel any sort of happiness or satisfaction. I was a dum brick in my heart and now it's gun for some time. That's the sort of feeling you get by not caring about your own creations. And yes, I do feel satisfied now. I could go on but I'd would loose any other progress in my life. Finally I know what to do when I get too old to work anymore. Hoping that I'll never need to justify my Lego gun work for whatever reason.
Motivated by my new Gun Disassembly toy I found a few interesting websites with interesting articles that made me realize that I don't really need to cut of my cartridge designs, just modify them a bit if I can. And almost all ideas I have consist of multiple cartridges and internal magazines - which's a good thing cause I almost started to throw this dream away. Inspired by the very interesting Mars Pistol I came up with an interesting idea of cycling a cartridge-based Lego gun. The cartridges are stored in an internal spring-powered magazine under the barrel. The top-most cartridge and the currently chambered cartridge reside in a rotatable revolver-like cylinder that can be pulled back and rotated, ejecting the chambered cartridge as well as moving the top-most cartridge into the chamber. The problem I see is how the cartridges are supposed to stick to the cylinder if you need both sides open for rechambering from the top side. Well, I guess I'll to find some clever use of bendable Lego parts for that. In chambered state, however, there's no rotation, just fixation. The complete operation does thus operates a bit like a bolt-action but with continuous rotation. Empty cartridges could theoretically even be dumped into a bag below... very interesting all that. The second interesting realisation I had was about derringer designs. They seem to just use an alternating striker position to trigger which barrel will be fired with a ratchet featuring alternating teeth height. Similar to how revolver rotate barrel with a ratchet, this approach just "rotates" the selected barrel. Using seperation of the rotating element and the ramming part, this should work I think. Hm, thinking of some more compactness, this could make a pistol-like gun with no cartridges at all... I'm even thinking about tri-barrel arangements if the rotating part gues well. Well, I'm totally into this thinking right now. Need to begin some drafts tomorrow evening, this could be fun... Oh and I don't even dare to think about starting construction cause I know I'll be depressed if Lego's ones again limiting my plans. Thus, I'm just doing a bit of daydreaming with schematics and drawings.
Do you know how difficult how it is to get any quality gun schematics for the sake of understanding, not to mention the hurdle of understanding them? It's probably a lot easier to buy a gun, replica or even toy gun to get the informations you want. However, there's an ingenious piece of software called Gun Disassembly 2, essentially a 3D animated version of those + schematics you can use to operate and observe the gun in different views. The name itself of course suggest assembly and disassembly, too, but that's not of interest to me. There's a real pack of different guns to selected. They modeled all internal parts and animations, packed them into different layers and made immensive comprehension it possibly to everyone. The software itself is free but you have to pay for the gun models (bought 7 models and got 40% discount). You can view any detail you want and possibly even incorporate your own animation data judging from the various debug options (just hit the 'd' key). I really recommend a try if you're into gun smithing, Lego/toy guns or just own a gun and want to understand it better. Also, if you never owned a gun or don't want to get one just to see how it looks under the hood (like me) you can't it high enough. It's the thing I always wanted in the past. Like all the gun schematics I ever desired to see in a single package. For example, I was able to find a revolver mechanic that's simple and sturdy enough to be done in Lego guns. I think I know what to do the time I'm building a Lego gun...
Over the last few days I've been working on some new Lego gun mechanics and also did an intensive research about how to realize a performant crossbow build build that doesn't bend Lego part. My current experiment consist of a bow with two "compressible"/spring-collapsable parts that feature limited rotation capabilities of around 45°. Combined with a wheel on each side and a closed bow string with on end below and the other atop the crossbow part, the bow ends can rotate 90° each for maximum compression. My initial idea was to create a Lego crossbow that can be drawn using a lever while rotating a cylinder since there's no string preventing rechambering. The problem's just that you'll still sorta need to bend Lego parts this way due to varied force vectors - pulling electrically might to trick but meh, that's not what I had in mind. The 90° compression stretches more than the rubber bands but the actual compression length is much less. I doubt is has more potential than my previous variant. The prolonged acceleration however could be more than I though - too bad I'll have to build a complete one before I can the bigger picture. So yeah, I'm having the same conceptional problems over and over again, whatever I do. I thought about still keeping the rubber band approach but modifiying it's release mechanic a bit to one that's more open to rechambering while charged. The idea behind this is to make the barrel open to a pin inserted from the bottom that'll pull the rubber band. Once fully stretched, the operation would feed a single projectile from bottom or top right before locking the projectile and releasing the rubber band. Cause the locking will work like in my 3x3xn cartridge design, the gun's ready to shoot it the rubber band pull mechanic is released. Interestingly, this would give a safety mechanic cause it won't shoot until you do a second action. That's around 5 small actions in total to shoot the gun, bah. Anyway, automating a bit here and there could make it viable I think. Atleast I'd have a step forward to automatable feeding mechanics. Of course I'll need to create a first model for it - otherwise I wouldn't be able to perfect the design and adapt to fit more automated mechanics. Design-wise it'd be a single-shot, bolt-action-alike model since you'd have to pull the rubber band all the time, leaving the chamber widee open after every shot. Hm, I guess it'd be a good idea to like the projectile lock to a flap designed to cover the open chamber. One shot and it'd open... Sounds nice to me.
there's an outstanding game called "Hotline Miami" a friend recommended to me. It's basically a top-down, insta-death game with stealth and speerun elements. You're playing some sort of killer instructed by seemingly nonsensic phone calls which will ultimately turn you into an excessively violent killing machine (Miami in the 80s as the game description mentions). It's like playing Dead Island for the first time ever while attempting to speedrun it on a one-shot-one-kill-super-fast-zombie diffculty. In two words: totally awesome! Exceptionally well-down presentation, an occupying soundtrack and very challenging, fast-paced gameplay. It's not impossible nor unfair, just based on death penalty for almost all wrong steps you can take followed by an almost immediate level segment restart. Oh and it even has an intriguing character concept: every time you start a level, you can put on a different animal mask giving you extra power like deadly hand-to-hand combat, the ability to survive a single shot, more gun drops and similar stuff. Every bit of the map has visibility properties to help beeing undetected or exposed to a dozen shotguns. There's even a limited sound-based orientation for the enemies which also have their own slightly varyings path and behaviour. It's actually the best killing simulator I ever encountered. Downsides are rather flimsy controls (though gamepad works quite well) and a less optimal menu system. Compared to what ingenius experience you get, however, it's nothing to bitch about. I should play more Indie games I discover via TIGSource (yes, I'm still reading blog part of this site) cause some community member do their very, very well. Despite my still persistent disagreement about the technology behind.
More than half a year ago I thought I finally got my way into matrices, but apparently it was just the "there's some stuff with effect" part. Exactly: This week I was simply unable to fulfill a task cause I didn't knew how to check a collision between an oriented bounding box and a point. You may think I'm a fool if you're into it. I was never able to imagine matrix and vector operations like I can with classic trigonometry, shape rendering, image/voxel data and so on. It's sorta beyond my understanding if it doesn't fit into my "space of thinking". I think in n-dimensional planes, time shifts and algorithmic whatever but simply can't put matrix and vector operations anywhere in my mind. I may be able to use them as a simply "cause and effect" tool but I can't get creative with it. Thus it's probably no wonder why I always try to reduce collision and rendering problems to axis-aligned boxes and circle cause they present the most simple and optimized with any complexity at all. See, this is bugging me. It always bugged when I couldn't understand something. I strife to understand things in total, not just beeing able to use it as a tool cause I can't stand coding with something I don't understand.. I decided do not bother with it anymore other than as a tool. It's against my believes but what I can't comprehend, I can't. But I'm good at a lot of other things in programming. I've always seen my unability to comprehend something I can't spatially understand as an embarrassing weakness. What if it isn't? What if exactly this "weakness" enables me to think differently? What would be my abilities if I'd be able to comprehend matrix mechanics but not about programming language design? Would I still have been able to immediately identify poorly written C++ libraries? Would I still be able to push C to a level where I can put a full sentinel node based linked list implementation into a single macro expression? Certainly not. The time I didn't spend trying to comprehend something I simply can't where spent with equally valuable experiences. After all, that's what makes our experiences, right? I shouldn't tell myself that I'm not a capable programmer just cause I'm not that into matrices. I was able to solve problems others didn't, I know my way in and around every aspect that's not related to matrices, graphics hardware or networking. Oh and don't tell me that's all what video game programming is about - you'd be surprised what other technical problems emerge during development and what tools and tool chains are needed to work around them. Well, I wouldn't call myself a tool programmer but that's most certainly one of the areas I can fit in easily. Workflow optimization, different complexity layers to take care of, a never-ending set of difficult problems... Yeah, one could say this sounds rather comftable to me. Anyway, I guess I'm over-estimating the role of this part of mathematics in game programming (like usual). So many ingenious games give a shit about it and yet they bloom to glory in their way of being some of the best games ever.
Ever blogged about shoes? I certainly never did but for some reasons I feel like I need to blog about it. I also never really thought about shows until the point where I really need new ones. I tend to wear some sort of sneakers but due to my more broad than long feet it's usually dum luck to find something that fits. Even worse, most shoes that fit break down in less than a year cause they tend to have air pocket in the sole, glue "melting" over time or other stuff indicating bad quality. So I decided to get some shoes that don't have most of these disadvantages cause it becomes more and more annoying to experience rain and snow inside my shoes. Also, since I became a vegetarian I felt bad about wearing leather shoes. My sister told me of an interesting shop called
Hooray! Finally some content on this blog related to programming. I've been working on my multithreading system for quite some time now and I was able to almost completely elimited all polling mechanic, complex thread linking operations and whatever else ugly was left. What I'm currently going for is an almost pure message passing and event based approach to communicate between threads. I had many fallbacks to the previous version but only now I got the essence of what makes message passing so awesome: it's strictness. Messages exist between two threads, there is no concurrency except when on message box access as multiple threads can send to one message box of one thread. However, it contradicts with my idea of creating a job/task system where any thread can wait for any job or task to be done. Both systems have their advantages and disadvantages but I prefer the message passing way cause it's simple, effective and clean compared to the other one. I encountered a bunch of problems on my way to still support random waiting on tasks loading and releasing resources. One way is to have each thread send their jobs/tasks to the worker thread/tasker and let the tasks only do work if the resource has not yet been loaded/released. Before scheduling a task, it'll check whether the resource is loaded or not, too. This ensure that already loaded resource won't be in schedule if it got loaded before but what about multiple threads sending their tasks all together waiting for one resource? One task will finish the job and the others cycle through until every thread got it's signal. But what if there's another huge resource right after the first task execution? The desired will already be loaded but the waiting threads will have to wait for the second resource though they could already continue their work. On a second thought... I'm using a single event to message ALL waiting threads so that can check their task's execution status. If I could somehow add a custom code to be called between... Well, this would make it possible to not only check for a task status but also for a resource status. Hmmm, I just need split the interface like I did before... Anyway, you see that there are always annoying bits to care about. I'm close to an optimal solution in terms of simplicity and efficiency merging. This'll be some good bachelor thesis result I think. All the time I'm getting a new idea it's based on just one idea I used to realize events with my qmutex construct. It's based on four functions calls in a row you can dynamically change in execution logic with some boolen triggers passed as params. The result can be a simple mutex, a query of waiting threads or a combinations of both depending on what code you do inbetween. I really love the concept but I find it hard to fully utilize cause I underestimate it's potential all the time. It's exactly what one needs if there's a complicated tradeoff to make between performance and complexity in terms of multithreading synchronization. Guess this is some sort of pioneer wor I got myself into. Darn. That's always the most annoying if you try to fully optimize something.