Monday, November 29, 2010
Tonight while playing Left 4 Dead 2, I noticed something a bit odd. The games textures for its "Desert Rifle" has markings for a MK 17 Mod 3 written on it along with an indicator of it being the 5.56x45mm variant.
That obvious error aside, what makes this odd to me. Just going on instinct from using the weapon in game rather than close look at the models, I would usually call it out as a SCAR or SCAR-H in game. The MK17 is the "Heavy" version firing 7.62x51mm. Someone later pointed out to me, that the magazines are obviously closer to the SCAR-L; the "Light" version of course, being the MK16 using the same 5.56x45mm you'll find on an M16 ;). The games stuff for the SCAR mags to me, look like a curved version of the SCAR-H mag.
Most of Left 4 Deads weapons have double their realistic ammunition capacity or close to it, adjusted for stopping power. Personally, I think that's a flaw but hey, bullets go even faster against zombies! The games SCAR hits more like a MK17 might be expected to, yet the games model appears to have an extended 30-round magazine; L4D does however exagerate the ballistics quite a lot for all the weapons. In game, you get 60 rounds in a SCAR firing on 3-round burst; the old school AR being a 50-round based M16 and the lovely AKM, offering 40 rounds.
3 times the real weapons ammo, can't beat that for shooting through waves of infected! The real odd thing I guess, is how I know just by looking at it, that the gun isn't accurate to real life :-/.
That obvious error aside, what makes this odd to me. Just going on instinct from using the weapon in game rather than close look at the models, I would usually call it out as a SCAR or SCAR-H in game. The MK17 is the "Heavy" version firing 7.62x51mm. Someone later pointed out to me, that the magazines are obviously closer to the SCAR-L; the "Light" version of course, being the MK16 using the same 5.56x45mm you'll find on an M16 ;). The games stuff for the SCAR mags to me, look like a curved version of the SCAR-H mag.
Most of Left 4 Deads weapons have double their realistic ammunition capacity or close to it, adjusted for stopping power. Personally, I think that's a flaw but hey, bullets go even faster against zombies! The games SCAR hits more like a MK17 might be expected to, yet the games model appears to have an extended 30-round magazine; L4D does however exagerate the ballistics quite a lot for all the weapons. In game, you get 60 rounds in a SCAR firing on 3-round burst; the old school AR being a 50-round based M16 and the lovely AKM, offering 40 rounds.
3 times the real weapons ammo, can't beat that for shooting through waves of infected! The real odd thing I guess, is how I know just by looking at it, that the gun isn't accurate to real life :-/.
Sunday, November 28, 2010
As pleasant as being able to install driver updates through the Windows update crap has been, I must admit that being dropped into a 640x480x4 desktop shows me just how horrible the old PCs used to look.
At least on my *nix systems, I've only got to worry about keeping kernel + X.Org + drivers in sync >_>.
At least on my *nix systems, I've only got to worry about keeping kernel + X.Org + drivers in sync >_>.
Saturday, November 27, 2010
First time for everything, right?
O.K. Now this was one of those has to be a first time for everything kind of moments. Sitting here, playing Left 4 Dead, we're having a brutal finale, so many freaking zombies I look like a mad dancer shoving and shooting while we fend off the horde.
All of a sudden I hear enough barking, flapping feathers, and pounding that it sounds like a war is going on down the hall in the living room. Shouted a quick BRB over VoIP while peeling off my headset and going to see what's exploding.
Found the ceiling fan going berzerk, parakeet going bananas, and the dogs trying to get to the bird lol. After shutting down the fan, ma noticed one of the fan blades were missing. Now absolutely nothing was disturbed anywhere. My mothers gots Thanksgiving decorations and religius stuff on the table, right next to the fan. Practically wall to wall there's breakable crap near there, birds cage is even in pissing distance of the fan (much to my annoyance). Close enough to opennings that it could even send the blade bouncing into the hallway or kitchen, if it came off at the right angle. To top it off, in the line of fire is a shelf full of my mothers dolls next to the couch.
It took at least 20+ minutes to find where the blade landed. Couldn't find it anywhere, no sign that it ever happened, except for the broken ceiling fan! While putting all that tactical study to good use and scannign the room, I had an AH HA! Moment.
Sure enough, the blade landed on a pillow on the couch. It was right in this trianglular sweet spot that's like a foot +/- a couple inches, from either point: My mothers head, Coco, and a small statue of the Virgin Mary by her computer. Statistically you would think that it's going to cream the stuff on the table, or maybe hit the bird or her dolls, but no.... smack dab right in between biologicals. A little bit more off that course, and either my mother would need a ice pack, or one of the dogs would need a vet lol.
Guardian angels or guardian angles, I think my mother finally has something to be thankful for... I know I am.
All of a sudden I hear enough barking, flapping feathers, and pounding that it sounds like a war is going on down the hall in the living room. Shouted a quick BRB over VoIP while peeling off my headset and going to see what's exploding.
Found the ceiling fan going berzerk, parakeet going bananas, and the dogs trying to get to the bird lol. After shutting down the fan, ma noticed one of the fan blades were missing. Now absolutely nothing was disturbed anywhere. My mothers gots Thanksgiving decorations and religius stuff on the table, right next to the fan. Practically wall to wall there's breakable crap near there, birds cage is even in pissing distance of the fan (much to my annoyance). Close enough to opennings that it could even send the blade bouncing into the hallway or kitchen, if it came off at the right angle. To top it off, in the line of fire is a shelf full of my mothers dolls next to the couch.
It took at least 20+ minutes to find where the blade landed. Couldn't find it anywhere, no sign that it ever happened, except for the broken ceiling fan! While putting all that tactical study to good use and scannign the room, I had an AH HA! Moment.
Sure enough, the blade landed on a pillow on the couch. It was right in this trianglular sweet spot that's like a foot +/- a couple inches, from either point: My mothers head, Coco, and a small statue of the Virgin Mary by her computer. Statistically you would think that it's going to cream the stuff on the table, or maybe hit the bird or her dolls, but no.... smack dab right in between biologicals. A little bit more off that course, and either my mother would need a ice pack, or one of the dogs would need a vet lol.
Guardian angels or guardian angles, I think my mother finally has something to be thankful for... I know I am.
Friday, November 26, 2010
Lately my dreams have been getting worse, really not sure if I should look forward to sleep or evade it at this point. On the upside, it beats boredom, on the down side it feels hours longer than the actual passage of time. That kind of adds up after a while, tiring.
I'm really not fond of holidays, haven't been for a very long time, doubt that's going to change anytime soon. As far as I'm concrened, just getting it done and over with is a good thing to me.
Really looking forward to getting started on the 30th. In the mean time, I've been experimenting with something. In setting up the Windows build for Cassius, I set things up to be able to use the systems lua build (i.e. on linux) or build it as a dependency of Cassius. That's gotten my brain cooking on making some reusable stuff out of it. Keyed in several libs so far, still need to iron a few things out, like moving header installation from premake time to prebuild time. While doing that and unrolling some loops, I also noticed a bug in some of the path.*() functions that premake uses. Seems that certain paths containing a $ need to be escaped (%$) IAW Lua's pattern matching syntax, or you get an invalid return value :-/.
Premake was actually my main reason for learning Lua, but never had much chance to use Premake until this month. Kind of been focused on C# the last kind of months, and largely using GNU Makefiles for that stuff. My principal gripes with using C/C++, is setting up Windows builds is a bitch and for most of my own stuff, I require software that works on both. On vaguely POSIX respecting systems, it's not that bad. One of these days I really need to work on setting up a linux or *bsd to windows cross compile.
One positive thing to come out of tinkering with a library (Cassius) for embedding programming languages. I've learned that Lua not only combines most of the features I like about JavaScript with a non CBF syntax, it also is a hell of a lot easier to build/embed then existing JavaScript engines \o/. For how much I like the Curly Brace Family versus the irk of embedding stuff, Lua is arguably the better choice in the trade off.
Two ways that I've collected so many languages, one is trying to use the tool most appropriate for what I need done, the other is I'm used to juggling between languages rapidly. Whatever the problem calls for and limits implementation headaches, rather than whatever is the 'mentally' convienant language of the moment. That's also some what a necessity of helping people here or there, can't quite say, "Sorry, brains in C mode, shove your PHP up your arse", now can I? lol.
Now if only the study of spoken languages were as trivial :-/.
I'm really not fond of holidays, haven't been for a very long time, doubt that's going to change anytime soon. As far as I'm concrened, just getting it done and over with is a good thing to me.
Really looking forward to getting started on the 30th. In the mean time, I've been experimenting with something. In setting up the Windows build for Cassius, I set things up to be able to use the systems lua build (i.e. on linux) or build it as a dependency of Cassius. That's gotten my brain cooking on making some reusable stuff out of it. Keyed in several libs so far, still need to iron a few things out, like moving header installation from premake time to prebuild time. While doing that and unrolling some loops, I also noticed a bug in some of the path.*() functions that premake uses. Seems that certain paths containing a $ need to be escaped (%$) IAW Lua's pattern matching syntax, or you get an invalid return value :-/.
Premake was actually my main reason for learning Lua, but never had much chance to use Premake until this month. Kind of been focused on C# the last kind of months, and largely using GNU Makefiles for that stuff. My principal gripes with using C/C++, is setting up Windows builds is a bitch and for most of my own stuff, I require software that works on both. On vaguely POSIX respecting systems, it's not that bad. One of these days I really need to work on setting up a linux or *bsd to windows cross compile.
One positive thing to come out of tinkering with a library (Cassius) for embedding programming languages. I've learned that Lua not only combines most of the features I like about JavaScript with a non CBF syntax, it also is a hell of a lot easier to build/embed then existing JavaScript engines \o/. For how much I like the Curly Brace Family versus the irk of embedding stuff, Lua is arguably the better choice in the trade off.
Two ways that I've collected so many languages, one is trying to use the tool most appropriate for what I need done, the other is I'm used to juggling between languages rapidly. Whatever the problem calls for and limits implementation headaches, rather than whatever is the 'mentally' convienant language of the moment. That's also some what a necessity of helping people here or there, can't quite say, "Sorry, brains in C mode, shove your PHP up your arse", now can I? lol.
Now if only the study of spoken languages were as trivial :-/.
Tuesday, November 23, 2010
Sunday, November 21, 2010
How I spent my early teens
While shuffling crap around yesterday, I found a folder full of undated papers. On one side are designs for a light strike cruiser and dreadnought done by hand in pencil, on the other side some edition of my Tallgeese manual done in MS Word and printed by the old Lexmark. I know from memory that the latter must've been done around the time frame of 2001-2003, so I must've been in the 13-15 range at the time. Majorly geeky years!
Basically, I had created my own "What if" story line, a place where my creativity could explore the possibilities without being tied down to anything existing, or having to start Totally From Scratch. I based it on a simple concept: what could happen if you fused parts of the Macross era of Robotech with the Universal Century and After Colony segments of Mobile Suit Gundam. It focused on adopting the character of Rick Hunter from an ace in the first robotect war, into a Lt. Col. leading a combined arms regiment from Earth Sphere United Nations during a massive conflict set in an "Alternate" version of life after Gundam Wing: Endless Waltz, one where the weapons of war had not been totally destroyed and world peace, still a hell of a lot further to go! That sentence is my definition of a run on, or at least a mouth full.
Part of that backdrop was focused on the details of one of my all time favourite mecha designs: Hajime Katokis Tallgeese. Some 15 years later it might look more like a Charger in a land of concept Camaros but I love this 'mech. In much the same vain that Treize Khushrenadas Tallgeese II was modelled after the original Tallgeese I, my theorical "Tallgeese IV" was modelled after the Tallgeese III seen in Endless Waltz.
Intro text on these papers state the Tallgeese IV was a custom made unit done in December of AC 196 (just before the Tallgeese III went into battle) and first deployed the following year. Gundam Wings original Tallgeese design is cannonically recorded as being done in the year AC 175, either on the show or in associated media. So obviously big changes were in order lol.
My design for the "OZ-00MS-IV Tallgeese IV" was drafted as weighing in at 8,200kg empty and reaching up to a gross weight of 27 metric tons fully loaded for a space battle, including a very variable arsenal of weapons. I've been known to make things exceptionally weapon laden, so is it any wonder that the original earh-side version of Heavyarms is of my favourite Gundam? (Heavyarms mounted about 7 (later 8) machine guns, four missile racks, and a heat knife.)
My Tallgeese IV was to have a hull made out of an enhanced (neo) titanium alloy, encasing a layer of ceramic polymer composites, then covered over with a layer of insulating materials on the inner side: a Beryllium based materal for shielding against radiation and a silicon covered network of titanium rods for some extra structural reinforcement. Even have a drawing in the printout (done in paint lol) showing the sandwiching of it all; cermaic between titanium and some insul' on the guts side. To do it all over again, I would probably research how useful a silicon or boron carbide in a titanium matrix (in laymen's terms that means it would costs mega bucks but could be fucking hard) might work out for that usage scenario, and likely rethink the whole Beryllium thing. All in all, it was basically made to be a 'mech with a very tough hide and library books didn't make the study of tank armour and advanced metal stuffs a trivial thing in the early A.D. 2000s.
Basically, super strong armour for protection, wrapped around a ceramic plate for stopping kinetic energy rounds, an armour backdrop and insulation between the armour and the guts.
For the cockpit, the design was to have a "Pod" like module mounted in the chest cavity behind the hatch. The idea being you would have an adaptive chair in the centre, yokes/joysticks on the flanks and a swivelled keyboard in front for details; I would add foot pedals to that, retrospectively. Encircling the pilot would be, basically an industrial strength LCD screen: displaying a 360' panorama of the 'mechs environment, using sensors built into the 'mechs body. Thus allowing the pilot to see anything he could hope to see (except straight up or down), and swivel the chair as needed to focus their peepers at any given point. How is that for eyes in the back of your head!? Note that 'mechs in Gundam Wing proper, only had a single front view screen. In case of critical failure, the pod was meant to be both ejectable and replacable: punching out with a few hours life support and enough thrusters to move to safety. Not to mention a hardware level to fry all the installed computer systems, in order to prevent an enemy from harvesting any data, or learning about the systems design in the event of capture.
The sections on computer systems is mostly useless from a technical specification but conceptually works well. Big picture wise, the idea was to use a subspace field to push the processing bottlenecks out of theoretical hardware and into the arena pure science fiction, ala converting the warp drive concept into a big ass CPU. Simple as that. At the time it seemed plausible enough that a Faster Than Light (FTL) processing speed might be necessary to keep pace with a combat mechs movements; this coming from someone who had just upgraded from a 233Mhz Pentium II to a 2,000Mhz Pentium 4 a a year or two before hand lololololol. To do things over again, I would use a mega load more of memory and see just how seriously parallel things could get between the hardware and software.
What is pertinent about computer systems described in it: is the concept of how it would be used as part of the overall machine. Conceptually things were meant to use a 'mech wide network of fibre optical cables to pass data from module to module, running this big distributed/multiplry redundant sort of internal computer network for keeping the 'mech working like a well oiled German sports car cruising down the Autobahn. These FO cables would be routed through several trunk locations at logical intervals, jacking the bandwidth as it were. These trunks would be placed at various points, like the legs, arms, etc, where important sensors could all link to conveniently and pass on their data. So many data trunks would be primaries and so many would be backups in order to cope with phsyical damage and the possibility of hardware failures, plus an extra set of three trunks for the cockpit: one emergency and two mains containing the heart of the 'mechs software environment, i.e. the master authority on all things computer related inside the mech.
Swap out the cockpit pod, and bingo: you would be able to overhaul the entire 'mechs computer systems. Anything that would have to be transferred (cached) at another trunk node, could be transferred from the mains in the cockpit pilot, much like a BIOS flash or an FTP install of Linux. Combining the FO cables with the link aggregation stuff, that should be pretty damn fast enough for anybodies conceivable needs, let along a battle field mechanic of the future >_>. At least that was the idea.
When I was writing this thing, the typical PC would likely still be using a 56K modem with a telephone line. Fiber Optic Internet, wasn't even talked about in these parts.
I also envisioned that for "Oh crap, everything has broken!" kind of situation, the a single data trunk would be *just* good enough to keep the Tallgeese IVs critical systems functioning, enough to walk/drift back to base for repairs, assuming the necessary cables were intact but the other computer modules offline. In order to make servicing internal components easier, a network of maintenance hatches, and corresponding "Jefferies tubes", so dubbed for lack of a better name, would run throughout the 'mechs body. What good is an extremely expensive, ultra advanced piece of war machine, if you can't fix the thing after it gets banged up, seriously, what's the point? On top of that would be fire suppression systems to suffocate an internal fires and a way to vent stuff over external fires for an emergency skin cooling.
Like wise, mirroring the networks for data transfer cables, would be systems for cooling and power distribution: including air ducting on the torso with filters, effectively allowing the pilot to breath regular air when earth side and not worry about tear gas, etc. For safety of course, being several sets (redundant) of ducting and putting a computer in place that could switch things around in case a duct got smashed up or severed, by dropping it and inserting a fresh segment, in order to avoid having to place the pilot on internal (space/underwater mode) life support.
As a safe guard against falling into enemy hands, a self destruct system was obviously called for. Both a near instant blow the sucker to kingdom come method, for use in case of being captured, that would be triggered via a hidden kill switch under the pilots seat, or by way of using keyboard and/or a voice activation mechanism to start a count down, for use in kamikaze style suicide. I'm crazy, right? A.) Don't let the enemy get your most advanced kit; B.) If all else fails, take them with you. Yep.
Since information is power, the Tallgeese IV would have a ton of sensor modules installed. Several arrays planted in the shoulder amour , feet, and head would provide targeting, radar, sensors for magnetic fields, seismic anomalies, infrared, sonar, and conventional radar. The idea being that if its a big hunk of hot metal stomping around, you ought to be able to figure out where it is ^_^.
Since it was set it was set in a story based on the Gundamverse, Minovsky particle based jamming technologies would make radar useless. Thus making most sensor applications limited to visual line of sight, and extras like being able to for example, using thermals and acoustics. I actually got the idea for using an infra system based on the FLIR pods used by the military; and the idea, "Well gee, if it can be forward looking, why not swivel it around!" Looking at that link, seems that kind of technology has existed since the 1960s. Good.
The 'mechs sensors would gather all that sensory input, route it through the trunks, processing as you go and create something fitting for the pilots view screens to display automagically. For extra benefit, an Initial Navigation System like mapping computer would "Remember" where you've walked/flown, and generate a form of spacial awareness. Today I would throw in a GPS too. It gives me a mental hard on just thinking about what programming something like all that might take... lol.
As a gimic, an experimental "Pilot to Mobile Suit Interface (P-MSI)" system was also planned for. Basically, scan the pilots brain in order to increase the response time. This could be thought of as an analogue to Gundams psycommu systems, adapted for regular humans, or a SLDF era Battle Mech helmet.
In terms of communications, several conventional and subspace radio systems would be mounted in the head module, along side a laser based LOS communication system for squad level use. The idea being, radio = fine until the Minovsky particles thicken up and jam it. One of the nifty but occasionally irksome parts of the UC segment of the gundamverse. So in essence, communication is limited to line of sight crap.
For getting around, obviously the Tallgeese design calls for a set of big ass engines. Basically the papers envision a type of nuclear thermal rocket, powered by taps into the 'mechs reactor: plus the ability to jettison them (and go ground pounding), frying the data trunks in the process. Leaving the secondary thrusters on the hips and rear skirt armour, just enough to perform manoeuvring in space or short rocket leaps in a terrestrial environment. Augmenting that, a set of computer controlled vernier thrusters for precision movements when operating in space. I always had trouble trying to calculate things like the theoretical acceleration rate and such, but I never had that big a grounding in math.
In terms of weapons, the Tallgeese IV was simply an augmented Tallgeese III, modified to suit my tastes. The Big Freaking Mega Cannon mounted on the right shoulder armour was replaced with something more practical yet still highly , that essentially combines a Variable Speed Beam Rifle with a Vayeate style Mega Particle Cannon. Conceptually, it would allow the pilot to dynamically adjust the beam width, pulse length (constant or pulse fired), and power rating. More powerful shots draining energy faster but being able to seriously maintain the DooM title of BFG! A way to self destruct the gun by over charging it, of course being in the concept, hehe.
Backing that up being external weapons. Power linkages inthe hands would allow the use of any Standard beam rifle or conventional autocannon (105mm/40rnd box magazine fed being the standard issue), including a heavy beam cannon designed to serve as a bazooka type shock weapon. It could also mount a 140mm cannon in place of the Mega Cannon.
The real emphasis was on melee weapons: a retractable 25 metre long "Heat" rod was built into a shield mounted on the left shoulder armour, containing a pair of beam sabers and 2-tube missile launchers. Increasing the thick plates defensive ability, the shield was to have a 20mm ablative coating for protection against directed energy weapons, and a low power I-field generator to reflect shots from low powered beam rifles. Tallgeese IV was also designed to have three beam sabers: two stored in recharge racks in the shield, and another hidden within the forearm for use as a backup. Since the Gundamverses beam sabers are essentially a power cell that spews plasma into an I-field, it would obviously be able to melt many conventional bullets on impact, the main sabers would be upgraded to use a denser I-field, in order to reflect shots from low powered beam rifles. Actually making that a useful weapon (Jedi style) however, is rather beyond the capability of a human pilot, without seriously jacking up the computing power.
A pair of head mounted 60mm Vulcan cannons with about 5 seconds of ammo rounded out a rather, comprehensive armament package.
Basically, I had created my own "What if" story line, a place where my creativity could explore the possibilities without being tied down to anything existing, or having to start Totally From Scratch. I based it on a simple concept: what could happen if you fused parts of the Macross era of Robotech with the Universal Century and After Colony segments of Mobile Suit Gundam. It focused on adopting the character of Rick Hunter from an ace in the first robotect war, into a Lt. Col. leading a combined arms regiment from Earth Sphere United Nations during a massive conflict set in an "Alternate" version of life after Gundam Wing: Endless Waltz, one where the weapons of war had not been totally destroyed and world peace, still a hell of a lot further to go! That sentence is my definition of a run on, or at least a mouth full.
Part of that backdrop was focused on the details of one of my all time favourite mecha designs: Hajime Katokis Tallgeese. Some 15 years later it might look more like a Charger in a land of concept Camaros but I love this 'mech. In much the same vain that Treize Khushrenadas Tallgeese II was modelled after the original Tallgeese I, my theorical "Tallgeese IV" was modelled after the Tallgeese III seen in Endless Waltz.
Intro text on these papers state the Tallgeese IV was a custom made unit done in December of AC 196 (just before the Tallgeese III went into battle) and first deployed the following year. Gundam Wings original Tallgeese design is cannonically recorded as being done in the year AC 175, either on the show or in associated media. So obviously big changes were in order lol.
My design for the "OZ-00MS-IV Tallgeese IV" was drafted as weighing in at 8,200kg empty and reaching up to a gross weight of 27 metric tons fully loaded for a space battle, including a very variable arsenal of weapons. I've been known to make things exceptionally weapon laden, so is it any wonder that the original earh-side version of Heavyarms is of my favourite Gundam? (Heavyarms mounted about 7 (later 8) machine guns, four missile racks, and a heat knife.)
My Tallgeese IV was to have a hull made out of an enhanced (neo) titanium alloy, encasing a layer of ceramic polymer composites, then covered over with a layer of insulating materials on the inner side: a Beryllium based materal for shielding against radiation and a silicon covered network of titanium rods for some extra structural reinforcement. Even have a drawing in the printout (done in paint lol) showing the sandwiching of it all; cermaic between titanium and some insul' on the guts side. To do it all over again, I would probably research how useful a silicon or boron carbide in a titanium matrix (in laymen's terms that means it would costs mega bucks but could be fucking hard) might work out for that usage scenario, and likely rethink the whole Beryllium thing. All in all, it was basically made to be a 'mech with a very tough hide and library books didn't make the study of tank armour and advanced metal stuffs a trivial thing in the early A.D. 2000s.
Basically, super strong armour for protection, wrapped around a ceramic plate for stopping kinetic energy rounds, an armour backdrop and insulation between the armour and the guts.
For the cockpit, the design was to have a "Pod" like module mounted in the chest cavity behind the hatch. The idea being you would have an adaptive chair in the centre, yokes/joysticks on the flanks and a swivelled keyboard in front for details; I would add foot pedals to that, retrospectively. Encircling the pilot would be, basically an industrial strength LCD screen: displaying a 360' panorama of the 'mechs environment, using sensors built into the 'mechs body. Thus allowing the pilot to see anything he could hope to see (except straight up or down), and swivel the chair as needed to focus their peepers at any given point. How is that for eyes in the back of your head!? Note that 'mechs in Gundam Wing proper, only had a single front view screen. In case of critical failure, the pod was meant to be both ejectable and replacable: punching out with a few hours life support and enough thrusters to move to safety. Not to mention a hardware level to fry all the installed computer systems, in order to prevent an enemy from harvesting any data, or learning about the systems design in the event of capture.
The sections on computer systems is mostly useless from a technical specification but conceptually works well. Big picture wise, the idea was to use a subspace field to push the processing bottlenecks out of theoretical hardware and into the arena pure science fiction, ala converting the warp drive concept into a big ass CPU. Simple as that. At the time it seemed plausible enough that a Faster Than Light (FTL) processing speed might be necessary to keep pace with a combat mechs movements; this coming from someone who had just upgraded from a 233Mhz Pentium II to a 2,000Mhz Pentium 4 a a year or two before hand lololololol. To do things over again, I would use a mega load more of memory and see just how seriously parallel things could get between the hardware and software.
What is pertinent about computer systems described in it: is the concept of how it would be used as part of the overall machine. Conceptually things were meant to use a 'mech wide network of fibre optical cables to pass data from module to module, running this big distributed/multiplry redundant sort of internal computer network for keeping the 'mech working like a well oiled German sports car cruising down the Autobahn. These FO cables would be routed through several trunk locations at logical intervals, jacking the bandwidth as it were. These trunks would be placed at various points, like the legs, arms, etc, where important sensors could all link to conveniently and pass on their data. So many data trunks would be primaries and so many would be backups in order to cope with phsyical damage and the possibility of hardware failures, plus an extra set of three trunks for the cockpit: one emergency and two mains containing the heart of the 'mechs software environment, i.e. the master authority on all things computer related inside the mech.
Swap out the cockpit pod, and bingo: you would be able to overhaul the entire 'mechs computer systems. Anything that would have to be transferred (cached) at another trunk node, could be transferred from the mains in the cockpit pilot, much like a BIOS flash or an FTP install of Linux. Combining the FO cables with the link aggregation stuff, that should be pretty damn fast enough for anybodies conceivable needs, let along a battle field mechanic of the future >_>. At least that was the idea.
When I was writing this thing, the typical PC would likely still be using a 56K modem with a telephone line. Fiber Optic Internet, wasn't even talked about in these parts.
I also envisioned that for "Oh crap, everything has broken!" kind of situation, the a single data trunk would be *just* good enough to keep the Tallgeese IVs critical systems functioning, enough to walk/drift back to base for repairs, assuming the necessary cables were intact but the other computer modules offline. In order to make servicing internal components easier, a network of maintenance hatches, and corresponding "Jefferies tubes", so dubbed for lack of a better name, would run throughout the 'mechs body. What good is an extremely expensive, ultra advanced piece of war machine, if you can't fix the thing after it gets banged up, seriously, what's the point? On top of that would be fire suppression systems to suffocate an internal fires and a way to vent stuff over external fires for an emergency skin cooling.
Like wise, mirroring the networks for data transfer cables, would be systems for cooling and power distribution: including air ducting on the torso with filters, effectively allowing the pilot to breath regular air when earth side and not worry about tear gas, etc. For safety of course, being several sets (redundant) of ducting and putting a computer in place that could switch things around in case a duct got smashed up or severed, by dropping it and inserting a fresh segment, in order to avoid having to place the pilot on internal (space/underwater mode) life support.
As a safe guard against falling into enemy hands, a self destruct system was obviously called for. Both a near instant blow the sucker to kingdom come method, for use in case of being captured, that would be triggered via a hidden kill switch under the pilots seat, or by way of using keyboard and/or a voice activation mechanism to start a count down, for use in kamikaze style suicide. I'm crazy, right? A.) Don't let the enemy get your most advanced kit; B.) If all else fails, take them with you. Yep.
Since information is power, the Tallgeese IV would have a ton of sensor modules installed. Several arrays planted in the shoulder amour , feet, and head would provide targeting, radar, sensors for magnetic fields, seismic anomalies, infrared, sonar, and conventional radar. The idea being that if its a big hunk of hot metal stomping around, you ought to be able to figure out where it is ^_^.
Since it was set it was set in a story based on the Gundamverse, Minovsky particle based jamming technologies would make radar useless. Thus making most sensor applications limited to visual line of sight, and extras like being able to for example, using thermals and acoustics. I actually got the idea for using an infra system based on the FLIR pods used by the military; and the idea, "Well gee, if it can be forward looking, why not swivel it around!" Looking at that link, seems that kind of technology has existed since the 1960s. Good.
The 'mechs sensors would gather all that sensory input, route it through the trunks, processing as you go and create something fitting for the pilots view screens to display automagically. For extra benefit, an Initial Navigation System like mapping computer would "Remember" where you've walked/flown, and generate a form of spacial awareness. Today I would throw in a GPS too. It gives me a mental hard on just thinking about what programming something like all that might take... lol.
As a gimic, an experimental "Pilot to Mobile Suit Interface (P-MSI)" system was also planned for. Basically, scan the pilots brain in order to increase the response time. This could be thought of as an analogue to Gundams psycommu systems, adapted for regular humans, or a SLDF era Battle Mech helmet.
In terms of communications, several conventional and subspace radio systems would be mounted in the head module, along side a laser based LOS communication system for squad level use. The idea being, radio = fine until the Minovsky particles thicken up and jam it. One of the nifty but occasionally irksome parts of the UC segment of the gundamverse. So in essence, communication is limited to line of sight crap.
For getting around, obviously the Tallgeese design calls for a set of big ass engines. Basically the papers envision a type of nuclear thermal rocket, powered by taps into the 'mechs reactor: plus the ability to jettison them (and go ground pounding), frying the data trunks in the process. Leaving the secondary thrusters on the hips and rear skirt armour, just enough to perform manoeuvring in space or short rocket leaps in a terrestrial environment. Augmenting that, a set of computer controlled vernier thrusters for precision movements when operating in space. I always had trouble trying to calculate things like the theoretical acceleration rate and such, but I never had that big a grounding in math.
In terms of weapons, the Tallgeese IV was simply an augmented Tallgeese III, modified to suit my tastes. The Big Freaking Mega Cannon mounted on the right shoulder armour was replaced with something more practical yet still highly , that essentially combines a Variable Speed Beam Rifle with a Vayeate style Mega Particle Cannon. Conceptually, it would allow the pilot to dynamically adjust the beam width, pulse length (constant or pulse fired), and power rating. More powerful shots draining energy faster but being able to seriously maintain the DooM title of BFG! A way to self destruct the gun by over charging it, of course being in the concept, hehe.
Backing that up being external weapons. Power linkages inthe hands would allow the use of any Standard beam rifle or conventional autocannon (105mm/40rnd box magazine fed being the standard issue), including a heavy beam cannon designed to serve as a bazooka type shock weapon. It could also mount a 140mm cannon in place of the Mega Cannon.
The real emphasis was on melee weapons: a retractable 25 metre long "Heat" rod was built into a shield mounted on the left shoulder armour, containing a pair of beam sabers and 2-tube missile launchers. Increasing the thick plates defensive ability, the shield was to have a 20mm ablative coating for protection against directed energy weapons, and a low power I-field generator to reflect shots from low powered beam rifles. Tallgeese IV was also designed to have three beam sabers: two stored in recharge racks in the shield, and another hidden within the forearm for use as a backup. Since the Gundamverses beam sabers are essentially a power cell that spews plasma into an I-field, it would obviously be able to melt many conventional bullets on impact, the main sabers would be upgraded to use a denser I-field, in order to reflect shots from low powered beam rifles. Actually making that a useful weapon (Jedi style) however, is rather beyond the capability of a human pilot, without seriously jacking up the computing power.
A pair of head mounted 60mm Vulcan cannons with about 5 seconds of ammo rounded out a rather, comprehensive armament package.
Saturday, November 20, 2010
Crankin' up the radio
I've got to admit, friends are right in that actually sleeping from time to time is a good idea. The last few weeks has been spent on minimal sleep levels, as usual for me. Thursday night/Friday morning, I just skipped sleeping, wasn't tired until like 1100 Friday, and that only lasted like fifteen-twnety minutes, then caught up with me half a day later. I took a friends advice and got some rest, rather than waiting until the 29th, now I'm super charged again. Guess I'll try and take it easy for a while, rather than focusing on how much stuff I can get done in spare time.
Of course though, my idea of taking it easy is nothing like sitting on my ass, hahaha! Going to get things shifted about, go through my back log of cleaning. I would like to transition to a more normal sleep routine, but that remains to be seen. I also need to get a few things sorted on Cassius, been refining things on the one branch for a while but haven't had time to step back and prepare it for commit; once things are sorted and I've selected a branch to merge into the mainline, I'll schedule time to sit back and do a review of things. After that I'll probably find a safe place for storing it, as safe guard against all my computers popping a cork \o/. I'm one of those backup freaks lol.
Over the years, I've spent enough of my life running on reserves that a little quality R&R gets me pumped up. I'm also not the kind of person who likes to be idle that much, programming at least exercises my thinking muscles a little bit. Right now I feel like I could jog twenty miles, but my feet would keep me if I did that! Actually, it's kind of funny. When I was a little kid, inside my own head I always used to refer to my energy levels as "Normal", "Auxiliary", "Reserve", and "Emergency" power. As an adult, my batteries don't recharge so fast any more, sure as hell don't last as long either: but consistently, the endurance level is still there lol. The real question is whether or not that'll hold through to when I'm old, grey, and lucky if I can still piss under my own steam >_>.
The things that get me tired tend to differ from "Norms", maybe it's because I'm insane or that I hate having nothing to work on, dunno. Either way, time to crank up the radio, get off the PC for a bit, and get stuff done.
Crazy way of relaxing, eh?
Of course though, my idea of taking it easy is nothing like sitting on my ass, hahaha! Going to get things shifted about, go through my back log of cleaning. I would like to transition to a more normal sleep routine, but that remains to be seen. I also need to get a few things sorted on Cassius, been refining things on the one branch for a while but haven't had time to step back and prepare it for commit; once things are sorted and I've selected a branch to merge into the mainline, I'll schedule time to sit back and do a review of things. After that I'll probably find a safe place for storing it, as safe guard against all my computers popping a cork \o/. I'm one of those backup freaks lol.
Over the years, I've spent enough of my life running on reserves that a little quality R&R gets me pumped up. I'm also not the kind of person who likes to be idle that much, programming at least exercises my thinking muscles a little bit. Right now I feel like I could jog twenty miles, but my feet would keep me if I did that! Actually, it's kind of funny. When I was a little kid, inside my own head I always used to refer to my energy levels as "Normal", "Auxiliary", "Reserve", and "Emergency" power. As an adult, my batteries don't recharge so fast any more, sure as hell don't last as long either: but consistently, the endurance level is still there lol. The real question is whether or not that'll hold through to when I'm old, grey, and lucky if I can still piss under my own steam >_>.
The things that get me tired tend to differ from "Norms", maybe it's because I'm insane or that I hate having nothing to work on, dunno. Either way, time to crank up the radio, get off the PC for a bit, and get stuff done.
Crazy way of relaxing, eh?
Wednesday, November 17, 2010
Early yesterday morning, I got an e-mail from someone interested in a rounder with some ability at rails, and asking about my availability. Decided to sleep on it after doing a quick review of the company. I wonder what's changed, that I haven't been getting so many doors slammed in my face :-/. Spent most of the day focused on a branch of Cassius.
Sometime after setting my laptop on the table and firing up the desktop for a quick game break between interruptions, when checking the laptop, I noticed a pop up message saying something about an incoming call. Loading the stuff on my desktop crashed the game, but well, it was worth it lol. Seems the business that had me in for an interview wants me to show up again, and it sounds like things are going to another level :-). One condition is that I get a GED, which perfectly plays to my favour: that means I can get it sooner rather than later. Since then, I've mostly been trying to get stuff in order via an action plan. I figure, may as well have everything sorted and ready to roll, straighten up the car, etc and maybe hit the library a bit, hehe. I like things being organised.
The real twist of my brains interest circuits, the companies name is very similar to someone I've known for years. Similar enough that I'm getting finger twisted, and have to re-read the names as I type them lol.
Sometime after setting my laptop on the table and firing up the desktop for a quick game break between interruptions, when checking the laptop, I noticed a pop up message saying something about an incoming call. Loading the stuff on my desktop crashed the game, but well, it was worth it lol. Seems the business that had me in for an interview wants me to show up again, and it sounds like things are going to another level :-). One condition is that I get a GED, which perfectly plays to my favour: that means I can get it sooner rather than later. Since then, I've mostly been trying to get stuff in order via an action plan. I figure, may as well have everything sorted and ready to roll, straighten up the car, etc and maybe hit the library a bit, hehe. I like things being organised.
The real twist of my brains interest circuits, the companies name is very similar to someone I've known for years. Similar enough that I'm getting finger twisted, and have to re-read the names as I type them lol.
Tuesday, November 16, 2010
Well ma has managed to interrupt me for over a solid hour, so I'm taking a break. So much for trying to get anything done, \o/.
I've been experimenting with exporting functions to scripts through Cassius::Engine, one branch oriented towards heavier templating, one branch towards a C++0X only solution, and one towards a more flat method for runtime (ab)use. Now if only I had 36-hour days and some time to myself, that doesn't involve being buggered off the computer
I've been experimenting with exporting functions to scripts through Cassius::Engine, one branch oriented towards heavier templating, one branch towards a C++0X only solution, and one towards a more flat method for runtime (ab)use. Now if only I had 36-hour days and some time to myself, that doesn't involve being buggered off the computer
Monday, November 15, 2010
OK, now I an officially surprised with life. Years ago I had applied to some tech jobs and was turned down via automated emails sometime later. Fast forward to the present, and I actually hear something from one of those companies lol.
Being more than a wee bit suspicious of things coming in out of the blue. Like seriously, what's the probability? What personal info that I have revealed, can be found trivially about me by any one doing their home work decently, so I'm not worried. The thing that bought that much level of trust out of me, was being told facts about the app' I had dropped in (when, to where, to what), that no one but me could know: assuming that such a reputable company didn't bungle their security, and no one was sniffing packets off our wires at the time. It's kind of like having a message from someone with a pre shared key that you trust, enough not to redirect to /dev/null but not enough to drop the deflector screen.
The real question is whether or not it leads to a viable job offer; I've no idea whether or not that one job interview will bear fruit. The insane thing, lacking a B.S. I've largely given up applying to tech jobs a long time ago, so recently I have focused on finding "Conventional" jobs in my area rather than things worth the effort.
Every thing that has come up in the past few weeks, all of them have been tech related!!! Sometimes I really wonder if someone up there has a sense of humour, one like mine anyway. But interviews, calls, and emails, still isn't being hired, even if it is an improvement. Computers are one of the things that know the most about out of everything I know, computers are what I've spent most of the decade glued to and what I've been using most of my life. Wouldn't it be bloody nice, if someone hired me to do something "Interesting" with them for a change?
Being more than a wee bit suspicious of things coming in out of the blue. Like seriously, what's the probability? What personal info that I have revealed, can be found trivially about me by any one doing their home work decently, so I'm not worried. The thing that bought that much level of trust out of me, was being told facts about the app' I had dropped in (when, to where, to what), that no one but me could know: assuming that such a reputable company didn't bungle their security, and no one was sniffing packets off our wires at the time. It's kind of like having a message from someone with a pre shared key that you trust, enough not to redirect to /dev/null but not enough to drop the deflector screen.
The real question is whether or not it leads to a viable job offer; I've no idea whether or not that one job interview will bear fruit. The insane thing, lacking a B.S. I've largely given up applying to tech jobs a long time ago, so recently I have focused on finding "Conventional" jobs in my area rather than things worth the effort.
Every thing that has come up in the past few weeks, all of them have been tech related!!! Sometimes I really wonder if someone up there has a sense of humour, one like mine anyway. But interviews, calls, and emails, still isn't being hired, even if it is an improvement. Computers are one of the things that know the most about out of everything I know, computers are what I've spent most of the decade glued to and what I've been using most of my life. Wouldn't it be bloody nice, if someone hired me to do something "Interesting" with them for a change?
- Having an occasional link on SpiderMonkey's docs that actually throws you to MDN, is rather tiresome.
- GDB doesn't always like dlopen()'ing a library that depends on (p)threads, using LD_PRELOAD fixes.
- Reading a functions documentation over again is more useful than a debugger, especially when you're tired.
- Lua's C API is really spoiling me.
- I know better than to git commit without sleep.
- Hmm, I wonder how long it would take this old laptop to compile V8... heh, can't be that bad.
For now my plan is grab a quick snack, check the server list, and pass out sometime around dawn, then review the files in the morning. Sometime when I'm fresh, I need to focus on an interface between C++ and the engines loaded by Cassius. The partial SpiderMonkey and unfinished V8 support can largely wait until later.
Of course, the reason why I named the base class for embedding a language 'Engine' rather than sometime more conventional, is in order to have a 'Cassius::V8Engine' in there, haha!
Sunday, November 14, 2010
*groan* today is time for the drop test—dropping things on MSVCs foot and hoping I don't feel like drop kicking it ^_^.
My life would probably be a lot easier if I just rigged a cross compiler and gave up on using a platforms more 'native' compilers, i.e. Visual C++ on Windows. It's about as much a native compiler as the platform has, and I still consider it insulting that a C compiler isn't provided as part of a Windows install lol.
My life would probably be a lot easier if I just rigged a cross compiler and gave up on using a platforms more 'native' compilers, i.e. Visual C++ on Windows. It's about as much a native compiler as the platform has, and I still consider it insulting that a C compiler isn't provided as part of a Windows install lol.
Grrr, almost 0400R. I actually had planned to get to bed early but dinner kind of threw the nights schedule for a loop :-/.
Hmm, food and SpiderMonky or food and Z's. Problem is I'm more hungry than sleeply lol. I really wish I could get work done in my sleep, or that days were at least 36 hours long.
Hmm, food and SpiderMonky or food and Z's. Problem is I'm more hungry than sleeply lol. I really wish I could get work done in my sleep, or that days were at least 36 hours long.
Post dinner notes
One value that this comment has served along with my compiler, is to teach me that default parameters on a template *function* are actually a C++0x feature, and apparently not part of C++03 as I have assumed for ages.
Somehow, I always figured if you could do it on template classes it would be legal on template functions as well. Guess that's what I get for never reading the ISO C++ 2003 standard, and it having been a number of years since I last RTFM so to speak \o/. About 95% of the times I use templates, it's at the class level anyway, and most queries I have on C++ are easily solved by reading a header file. To be honest, while the drafts for C99 make for a very nice read, I've always worried that digging into the C++ standards might melt my brain or put me soundly to sleep. Frankly, C standards are helpful along side SUS, but the standards for C++, well all I can say is that I'll be happy when 0x becomes as omnipresent as C89 capable C compilers. I'm just not sure I will live that long though :-(.
What I've done is implemented Engine::Call() as a sequence of template functions that use the vaguely normal method overloading semantics to cope with the arguments through Push(). Nothing else has been able to maintain the desired level of type safety. Basically if Call gets 0 arguments = use the current class state, and successive versions of Call(funcname, ...) doing the obvious manipulations to generate the correct state and than run it. I would rather a recursive variadic template but life sucks and C++0x isn't every where just yet. Having to supporting late model GCC 3.x is a real possibility for Cassius to bear fruit without thinning a few hedges.
Push() is just done as a set of virtual member functions for logistical reasons. Since each Engine instance is tagged with it's language and implementation details (as an insurance policy), the same effect could be done through a set of template specializations and a little static_cast magic to forward it to the correct subclass without any inheritance tricks. At the price of a more stringent contract with subclasses, that would also allow for getting rid of other virtual members in the base class. I'm not what instructions a C++ compiler is likely to generate for a static_cast from parent to child class compared to what C++ virtual methods and casting things in C land will produce, but I could really care less about the cost of using virtual Push()'s versus templated Push()'s here: Call() is the one that matters at the template level. Why virtuals are used for Push() in point of fact, is to avoid a build time dependency against the backends (to be loaded at runtime), which obviously would be a circular dependency. So templated Call(), virtual Push() works more convineantly than a purely templated driven solution.
Being sublimely lazy, rather than write out a set of similar template functions for each version of Call() that's needed to handle these successive amounts of arguments, I just wrote a Lua script to do it for me: then shoved that into the projects build scripts and adjusted the headers to include that auto generated file as needed. One of my favourite Boost libraries actually does something similar for handling a variable number arguments for a functor type class, but I'll be damned if I'm writing them by hand!
Lately I've been relying on a mixture of rake (Ruby) and premake (Lua) based build systems, so it is rather nice to be able to do such things: and not kick myself later (make, vcbuild).
template <typename Num=int> Num square(Num n) { return n * n; }
int main() { return square(5); }
// g++ 4.5.1 reports:
//
// error: default template arguments may not be used in function
// templates without -std=c++0x or -std=gnu++0x
Somehow, I always figured if you could do it on template classes it would be legal on template functions as well. Guess that's what I get for never reading the ISO C++ 2003 standard, and it having been a number of years since I last RTFM so to speak \o/. About 95% of the times I use templates, it's at the class level anyway, and most queries I have on C++ are easily solved by reading a header file. To be honest, while the drafts for C99 make for a very nice read, I've always worried that digging into the C++ standards might melt my brain or put me soundly to sleep. Frankly, C standards are helpful along side SUS, but the standards for C++, well all I can say is that I'll be happy when 0x becomes as omnipresent as C89 capable C compilers. I'm just not sure I will live that long though :-(.
What I've done is implemented Engine::Call() as a sequence of template functions that use the vaguely normal method overloading semantics to cope with the arguments through Push(). Nothing else has been able to maintain the desired level of type safety. Basically if Call gets 0 arguments = use the current class state, and successive versions of Call(funcname, ...) doing the obvious manipulations to generate the correct state and than run it. I would rather a recursive variadic template but life sucks and C++0x isn't every where just yet. Having to supporting late model GCC 3.x is a real possibility for Cassius to bear fruit without thinning a few hedges.
Push() is just done as a set of virtual member functions for logistical reasons. Since each Engine instance is tagged with it's language and implementation details (as an insurance policy), the same effect could be done through a set of template specializations and a little static_cast magic to forward it to the correct subclass without any inheritance tricks. At the price of a more stringent contract with subclasses, that would also allow for getting rid of other virtual members in the base class. I'm not what instructions a C++ compiler is likely to generate for a static_cast from parent to child class compared to what C++ virtual methods and casting things in C land will produce, but I could really care less about the cost of using virtual Push()'s versus templated Push()'s here: Call() is the one that matters at the template level. Why virtuals are used for Push() in point of fact, is to avoid a build time dependency against the backends (to be loaded at runtime), which obviously would be a circular dependency. So templated Call(), virtual Push() works more convineantly than a purely templated driven solution.
Being sublimely lazy, rather than write out a set of similar template functions for each version of Call() that's needed to handle these successive amounts of arguments, I just wrote a Lua script to do it for me: then shoved that into the projects build scripts and adjusted the headers to include that auto generated file as needed. One of my favourite Boost libraries actually does something similar for handling a variable number arguments for a functor type class, but I'll be damned if I'm writing them by hand!
Lately I've been relying on a mixture of rake (Ruby) and premake (Lua) based build systems, so it is rather nice to be able to do such things: and not kick myself later (make, vcbuild).
Saturday, November 13, 2010
Spent yesterday trying to get back into the swing of things, first time I've actually logged on comms in a few days lol.
Last night I was watching The Others and Surrogates. The others might make some people feel creeped out but I only found its plot a bit overly clichéd. If the ending isn't obvious by first leg of the movie, it is by the half way point \o/. It does pose an interessting thought though. What if "Disturbances" that people feel are ghosts and hauntings and all that sort of stuff, is really just a conflict of matter? Where the living and the dead have crossed paths but nether know one is dead, or perhaps it's not death but something whacko in the space time continuum. Who knows, I still maintain that if ghosts exist, you're more likely to die in the bath tub than experience something like Poltergeist. I don't rule out the possibilities of ghosts, I just don't expect to ever see one ^_^.
The surrogates on the other hand, is an interesting sci fi flick. Basically people no longer "Go out" but instead control an avatar via remote. It follows a detectives hunt for a weapon that is able to kill the human operators behind their "Surrogates". While not exactly a spectacular movie, it explores an interesting concept, well interesting in light of the modern Internet. Being able to do anything without risk of life and limb, is an interesting idea, but I would argue that's part of what makes life worth living. After all, if you're going to go sky diving , what good is it, if you can't *really* experience it? It's only a facsimile of the real thing. For something like a fire fighter, IMHO it would be perfect but the ideal of living every day life through a surrogate, just, doesn't feel right to me.
Last night I was watching The Others and Surrogates. The others might make some people feel creeped out but I only found its plot a bit overly clichéd. If the ending isn't obvious by first leg of the movie, it is by the half way point \o/. It does pose an interessting thought though. What if "Disturbances" that people feel are ghosts and hauntings and all that sort of stuff, is really just a conflict of matter? Where the living and the dead have crossed paths but nether know one is dead, or perhaps it's not death but something whacko in the space time continuum. Who knows, I still maintain that if ghosts exist, you're more likely to die in the bath tub than experience something like Poltergeist. I don't rule out the possibilities of ghosts, I just don't expect to ever see one ^_^.
The surrogates on the other hand, is an interesting sci fi flick. Basically people no longer "Go out" but instead control an avatar via remote. It follows a detectives hunt for a weapon that is able to kill the human operators behind their "Surrogates". While not exactly a spectacular movie, it explores an interesting concept, well interesting in light of the modern Internet. Being able to do anything without risk of life and limb, is an interesting idea, but I would argue that's part of what makes life worth living. After all, if you're going to go sky diving , what good is it, if you can't *really* experience it? It's only a facsimile of the real thing. For something like a fire fighter, IMHO it would be perfect but the ideal of living every day life through a surrogate, just, doesn't feel right to me.
Friday, November 12, 2010
Currently Lua and Python are in the works, because Lua's API is different from what I'm used to, and Python is well, not fun to embed but simple enough. Conceptually there is no major difference between a parameter list and a stack, it's just a sequence of data at heart, and Python functions basically use sequence objects.
What would be awesome, is if the calls are defined in terms of stack manipulation, is to create a template method called Push, that users template specialisation in order to wrangle plain old data types and callables to the right scripting language types, so we would have something like this:
and rely on the compiler to Get It Right in figuring out the relevant overloads, e.g. Push. Somewhat probmatic is the issuance that Push needs to be part of the abstract base class but can only be defined by a concrete implementation of the interface; normally it would just be defined as a virtual method. That means it works like you would expect a class method to work by default \o/. Only thing with that is templates cannot be virtual, so we would have to sidestep the whole vtable thing.
That's a piece of cake thanks to C++ allowing the abuse of inheritance and casting:
Because the parent class is templated against the derived class, it's possible to get jiggy with it at compile time. Namely enough is known by the parent about the child to invoke the correct method. Where it becomes somewhat annoying is when you want to continue with subclasses, like X in the above example.
A year or two ago I learned that people call this the "Continually Reoccurring Template Pattern (CRTP)". Being lazy, I just think of it as the poor mans way of doing something similar to what "virtual template <...> ..." would logically imply, if only the effing compiler was that smart. For what I need, just mating instance method overloading with virtual method calls is good enough.
Now all that is trivial, the real gripe however is how do you properly make a "Convenience" method, let's say one we can do like e->Call(/* variable number of parameters */); and have it do the appropriate magic for us based on the type.
Well, sadly we can't so easily. To use a va_list, there has to be a way to access the type of the argument. Normally this is done the same way that printf() and scanf() work in C, taking a format string saying what type to cast each parameter to. Pythons embedding API actually does this to convert from C data types to Python objects. Someday I need to open up a C library and look at how va_arg() actually works, I've always assumed it's some sort of hack around a block of memory and type casting. It's trivial to implement that kind of thing, already have done it for testing purposes (rather than templated Push()'s) but using a format string to describe the specifiers breaks down on type safety, where as at least with the template thing, the compiler can help some.
We can't rely on Push() overloads to do the right thing because va_arg() is needed to access the arguments if Call() takes a variable number of arguments in the C++ 2003 compliant way. Obviously the easist solution is to find a smarter way of doing va_arg(a_va_list, a_type). Life would be a piece of cake with templates that can take a variable number of parameters, right? Well there's few vendors out there who seem to know how to do that <_>.
So how the fuck do you do a smart va_arg() like behaviour? The only thing I can think of at the moment is to make them all the same templated type, so it's known how to cast them; then try and work some sort of char_traits<> like magic to figure out which Push() is appropriate but binding the necessary info creates more of the same. That and looking up in the C++ standard how many template parameters (if any) compilers are required to allow, and generating every possible permutation of arguments using a script to make the necessary template code before calling the compiler.
Either way, I'm just taking a break for a few minutes to enjoy how peaceful the quiet has been for the last twenty minutes lol.
What would be awesome, is if the calls are defined in terms of stack manipulation, is to create a template method called Push, that users template specialisation in order to wrangle plain old data types and callables to the right scripting language types, so we would have something like this:
e->Run(SourceString("function f(a, b) print(a); return b * b end")
e->Push(/* instance of some type representing f() */);
e->Push("header message");
e->Push(2);
e->Call();
and rely on the compiler to Get It Right in figuring out the relevant overloads, e.g. Push
That's a piece of cake thanks to C++ allowing the abuse of inheritance and casting:
/* An example */
#include <iostream>
template<class Impl> class Base {
public:
template <typename T> void Push(T arg)
{
static_cast<Impl *>(this)->Push(arg);
}
};
// implementation
class Impl : Base<Impl>
{
public:
template <typename T> void Push(T arg);
};
template <> void Impl::Push (int arg)
{
std::cout << arg << std::endl;
}
template <> void Impl::Push (const char *arg)
{
std::cout << arg << std::endl;
}
// subclass that just overrides one method
class X : Impl {
public:
template <typename T> void Push(T arg);
};
template <> void X::Push (int arg)
{
std::cout << arg * arg << std::endl;
}
template <> void X::Push (const char *arg)
{
static_cast<Impl *>(this)->Push(arg);
}
int main()
{
{
Impl test;
test.Push(2); // 2
test.Push("string");
}
{
X test;
test.Push(2); // 4
test.Push("string");
}
return 0;
}
Because the parent class is templated against the derived class, it's possible to get jiggy with it at compile time. Namely enough is known by the parent about the child to invoke the correct method. Where it becomes somewhat annoying is when you want to continue with subclasses, like X in the above example.
A year or two ago I learned that people call this the "Continually Reoccurring Template Pattern (CRTP)". Being lazy, I just think of it as the poor mans way of doing something similar to what "virtual template <...> ..." would logically imply, if only the effing compiler was that smart. For what I need, just mating instance method overloading with virtual method calls is good enough.
Now all that is trivial, the real gripe however is how do you properly make a "Convenience" method, let's say one we can do like e->Call(/* variable number of parameters */); and have it do the appropriate magic for us based on the type.
Well, sadly we can't so easily. To use a va_list, there has to be a way to access the type of the argument. Normally this is done the same way that printf() and scanf() work in C, taking a format string saying what type to cast each parameter to. Pythons embedding API actually does this to convert from C data types to Python objects. Someday I need to open up a C library and look at how va_arg() actually works, I've always assumed it's some sort of hack around a block of memory and type casting. It's trivial to implement that kind of thing, already have done it for testing purposes (rather than templated Push()'s) but using a format string to describe the specifiers breaks down on type safety, where as at least with the template thing, the compiler can help some.
We can't rely on Push() overloads to do the right thing because va_arg() is needed to access the arguments if Call() takes a variable number of arguments in the C++ 2003 compliant way. Obviously the easist solution is to find a smarter way of doing va_arg(a_va_list, a_type). Life would be a piece of cake with templates that can take a variable number of parameters, right? Well there's few vendors out there who seem to know how to do that <_>.
So how the fuck do you do a smart va_arg() like behaviour? The only thing I can think of at the moment is to make them all the same templated type, so it's known how to cast them; then try and work some sort of char_traits<> like magic to figure out which Push() is appropriate but binding the necessary info creates more of the same. That and looking up in the C++ standard how many template parameters (if any) compilers are required to allow, and generating every possible permutation of arguments using a script to make the necessary template code before calling the compiler.
Either way, I'm just taking a break for a few minutes to enjoy how peaceful the quiet has been for the last twenty minutes lol.
Thursday, November 11, 2010
Despite being interrupted almost every five to fifteen minutes, I managed to get the backends for embedding Lua and Python sorted. Today I would like to start getting into making it useful for something besides evaluating scripts.
Cassius needs to allow two things in order to be useful to me: invoking the embedded languages procedures from C++, and a way to export code to the embedded language. My interest, is whether or not it's actually possible to accomplish that using fairly standard C++. I'm kind of hoping, to see just how far that can be pushed.
From experience, I've learned that you can expect something vaguely C89 compliant anywhere in the world but expecting C++ compilers to agree on all things template related, can be like asking a goldfish to walk on air - a bad idea! That's why I rarely do more with templates than I have to. With how much compilers have changed in the last four years, I reckon it's time.
Out of everything traditional C++ offers, most of it is just sub standard compared to newer languages. A lot of the code I've read over the years, I would hardly even count as C++ so much as C with classes, but people have developed reasons I guess. IMHO how C++ can interface with C code is a killer feature, that could be just as readily solved by adapting a C compiler to generate JNI glue code or some shit like that. Throwing on inheritance based OOP isn't that killer in my books, when you look at languages like Ruby and Python. The real killer feature of C++ is what you can do with templates. While supporting simple generics are part of it, that could be done in C by (abusing) the pre processor and adjusting your Makefile. It's the opportunities to get creative at compile time that make its it worth while, someday I really should see if any good books have been written on TMP in C++.
The way I look at it, macros make Common Lisp stand out from it's younger peers, C++ templates make you drool, or curse compilers more frequently lol. Leveraging languages is why more than one programming language should exist.
Cassius needs to allow two things in order to be useful to me: invoking the embedded languages procedures from C++, and a way to export code to the embedded language. My interest, is whether or not it's actually possible to accomplish that using fairly standard C++. I'm kind of hoping, to see just how far that can be pushed.
From experience, I've learned that you can expect something vaguely C89 compliant anywhere in the world but expecting C++ compilers to agree on all things template related, can be like asking a goldfish to walk on air - a bad idea! That's why I rarely do more with templates than I have to. With how much compilers have changed in the last four years, I reckon it's time.
Out of everything traditional C++ offers, most of it is just sub standard compared to newer languages. A lot of the code I've read over the years, I would hardly even count as C++ so much as C with classes, but people have developed reasons I guess. IMHO how C++ can interface with C code is a killer feature, that could be just as readily solved by adapting a C compiler to generate JNI glue code or some shit like that. Throwing on inheritance based OOP isn't that killer in my books, when you look at languages like Ruby and Python. The real killer feature of C++ is what you can do with templates. While supporting simple generics are part of it, that could be done in C by (abusing) the pre processor and adjusting your Makefile. It's the opportunities to get creative at compile time that make its it worth while, someday I really should see if any good books have been written on TMP in C++.
The way I look at it, macros make Common Lisp stand out from it's younger peers, C++ templates make you drool, or curse compilers more frequently lol. Leveraging languages is why more than one programming language should exist.
Tuesday, November 9, 2010
Relaxation time
One thing spending almost my entire life around computers has taught me, is that rarely is anything impossible, so much as it may just be a pain in the ass to get done. For R&R, my interest is in exploring whether or not a wrapper around scripting languages can really work without heavy introspection or SWIG style code generation.
Principally, embedding a scripting language amounts to initializing it, feeding it with code, and stitching together an interface between it and the desired parts of your C/C++ code. In my experience most time is spent on writing code to bridge C with the script language. It's kind of like an adaptor for calling conventions, but in C rather than native code.
The question that interests me, is whether or not C++'s standard issue functors and binders, are good enough that it could be done without having to to cuddling up to much to a specific scripting engines embedding API, for each one being embedded. In most dynamic languages the manipulations needed are pretty trivial, but C++ is rather, more traditional. Because of that curiosity, I've had an idea on my mind for ages, which I dub "Cassius". The idea is, to have an interface that knows how to embed several scripting languages, and use that to interface with the scripting languages, in a way more agnostic to which scripting language you're using.
I thought of the name as a reference both to the Roman name and to Cassius Clay, better known as Muhammad Ali—because after adding support for a embedding a few scripting languages, it might very well knock me out ^_^. The part that I'm not sure, is whether or not, it is technically possible to do it in straight C++, or if the APIs would require more than is possible without using something like SWIG.
Sometimes for a change, it's fun to ride an idea to the end of a tunnel without trying to speculate what's waiting there.
Principally, embedding a scripting language amounts to initializing it, feeding it with code, and stitching together an interface between it and the desired parts of your C/C++ code. In my experience most time is spent on writing code to bridge C with the script language. It's kind of like an adaptor for calling conventions, but in C rather than native code.
The question that interests me, is whether or not C++'s standard issue functors and binders, are good enough that it could be done without having to to cuddling up to much to a specific scripting engines embedding API, for each one being embedded. In most dynamic languages the manipulations needed are pretty trivial, but C++ is rather, more traditional. Because of that curiosity, I've had an idea on my mind for ages, which I dub "Cassius". The idea is, to have an interface that knows how to embed several scripting languages, and use that to interface with the scripting languages, in a way more agnostic to which scripting language you're using.
I thought of the name as a reference both to the Roman name and to Cassius Clay, better known as Muhammad Ali—because after adding support for a embedding a few scripting languages, it might very well knock me out ^_^. The part that I'm not sure, is whether or not, it is technically possible to do it in straight C++, or if the APIs would require more than is possible without using something like SWIG.
Sometimes for a change, it's fun to ride an idea to the end of a tunnel without trying to speculate what's waiting there.
Subscribe to:
Posts (Atom)