Jump to content

Nuke

Members
  • Posts

    3,736
  • Joined

  • Last visited

Everything posted by Nuke

  1. as i understand it the ram jets are mostly used to reduce drag and dont really produce any meaningful thrust. it also gives a way to dump the surplus hydrogen as well. the precooler needs more for coolant than the engine can burn, so there is a lot of surplus for the ramjets that would otherwise just need to be dumped. i actually think its one of the more clever parts of the design.
  2. if you watched the series you know that the newer battlestars were all being upgraded on the electronics front. galactica on the other hand was an old skool ship with an old skool commander, and thats why it was spared. also it didnt have #6 clones infiltrating every nook and crannie of their systems. i think the cylon's victories against the colonies were mostly successful because espionage level soviet.
  3. war exists because it increases the rate of entropy in the universe.
  4. it should work on any platform that supports the arduino ide. im not sure what arduinos it supports. definately not any of the 328p micros, anything based on a 32u4 will work. it compiled for the due but i haven't tested it yet (its got a mess of wires connected to it for another project). i also got a brand new stm32 board in my desk but i haven't even soldered on the headers yet, but il try and see if it compiles (it doesnt look like the stm32 package works for this version of arduino, id have to go back to 1.6.5, which doesnt support my library). update on the due, no workie. nope it works, you just need to #include "HID.h" at the top of the file and you have to use the native port.
  5. i have a feeling we will see the engines at least. i view the plane itself more as a loose concept rather than a final product, to give potential buyers of the engine an idea of what it can do. id love to give a couple of those engines to scaled composites and see what they could come up with.
  6. for those interested i finally posted my HID Joystick library to github https://github.com/LordNuke/ArduinoLibs im running this in 1.6.7 which has support for hid based libraries now. this made it very easy to make it a self contained package where before it was a dirty hack in my arduino core. glad that its a library proper now. so its pretty basic, supports 8 16-bit axes, 32 buttons, and a pair of 8-way hat switches. so far i tested it on the arduino leo and it appears to be working.
  7. they've certainly proven their metal in the game design world. id love to see what else they can do, at least when ksp dev slows down.
  8. please thats the only spelling error you could find? that post is full of them. i suppose fighters work for their universe to a degree given the ai enemy. the whole ship was build low tech for that very purpose. if you really wanted to throw a monkey wrench in their plans, you would make the missile guidance analog.
  9. well a battlestar is essentially a carrier in space. though i find some of its design choices questionable. those big retractable pods could probibly be replaced with fixed pods and save tons on actuators and rail systems and the like. i suppose its nice to be able to decelerate your fighters while under cover provided by the bays, but i dont see why the whole thing needs to move. it would be easier to just stick a large hatch on the pods, collect your birds, and close the hatch. i also dont get why you need so many, galactica's 2 and pegasus's 4. you could probibly take it down to 1 large bay with redundant hatches.then you have a whole other system for launching fighters. why not just fly out the bays? then why even go with a carrier? if you are gonna carry fighters, why not missiles instead? you can immediately ditch a third to half of ship's the bulk. you might still meed a raptor bay and a few vipers for recon and the like but not severa; squadrons. instead you have a bunch of missile tubes. or instead of tubes just a side hatch, eject your missiles and let them drift away from the ship before igniting the rockets and avoid altering the ships trajectory by firing ordinance. pegasus had those big railguns or whatever, and those could stay part of the design i suppose. i would make the projectiles semi-guided so they could apply some course corrections en route to the target. you impart all the kinetic energy from the launcher and use some lateral rcs thrusters to tweak the trajectory a little as a counter to evasive manuvers. the flak turrets would probibly be rather brutal for close in combat, even saturating a target's space with shrapnel would be rather devastating. while were taking away their unobtanium jump drives and their seemingly inexaustable fuel (and booze) supply. you take away from the bulkiness of the structure and replace it with tankage (3/4 fuel, 1/4 booze), you are left with a rather thin skinned but well armed tank of explosive stuff that is going to spend most of its time getting shot at by cylons. they did do one thing right by putting the c&c down in the bowels of the ship instead of sticking it on top of everything like they do in star trek. even star wars had big exposed bridges on the massive capital ships with huge windows that you can crash an xwing into. so brownie points for that.
  10. there are also a lot of newer nv memory technologies coming out the pipe (mram for example), some of them will have better durability than flash, use less power, and will be much faster too. we still dont have a consumer device that doesn't destroy itself with enough use (a few exist but in small packages not competitive with flash).
  11. say you wanted to do an artsy type game entirely in b&w. you would create all your art and whatnot in formats suited to grayscale data, color formats like dxt1 and 5 would probibly not be used at all (though you might use 5_nm for normal maps). you might as well break out bc4 textures. you are going to get much better grayscale representations for the same memory cost as dxt1. if you do that you might as well break out bc5 for normal maps. or you can speed things up by using the same format for everything. if you use array textures, where you can have any number of single channels of the same type and get a slightly improved performance improvement out of it (texture switching is expensive). most of your maps are going to be single channel. normal maps require 2 channels, but you can easily have once channel for u and another for v and connect the dots in the fragment shader, so an array of bc4s would work great. up till now you havent really gained anything but a little bit of performance using array textures. when you start writing fragment shaders you will find that your math gets much much more simple. you dont have to handle any color channels separately, just the gray values. you will see almost a 2/3rd drop in flop requirements from your stream processors. so you stand to have a bit of improved rendering performance out of that. you can throw those savings into graphics detail and come out with a rather visually stunning yet efficient game. however i dont think you can just flip a switch and throw out the color. your game has to be designed from the ground up for b&w rendering.
  12. you can hawk it and buy a pc.
  13. if you want to get technical flash is a memory crystal. its just stuck in a plastic case because its only a tiny sliver of moncrystalline silicon and is very fragile.
  14. i guess i didnt catch this one. actually i figure more robust coding schemes can be used given the speed of some of these dev boards we have. on one hand i dont really like the idea of solving every problem with the #include statement. on the other, i can use tried and true encoding systems instead of something i cobbled together based on some knowlege i had about dxtx formats and limited information theory. im somewhat curious what can be done with run length encoding, just zipping my compressed image file to less than half its original size, 7z gets it down a few hundred more bytes. so its certainly worth investigating (it has to beat 150 microseconds/block for compression/decompression though). i dont really need lossless since the main usage scenario is for putting cameras on rc vehicles, i dont need the video to be completely error free (if it works to a km or two vs the 200 or so feet my analog camera gets its an improvement, not to mention i wont have to re adjust the receiver every 3 seconds). even if half the blocks are garbled i can still navigate. good idea measuring the error, much more scientific than "hey that looks better, this other one looks like crap". i still dont have a decent 8-bit codec, so much more testing on that reguard. and i need to find a library for my camera module first. *edit* i just did my fixed point math revision and got decompression and display down to < 60 microseconds! regardless off the beefiness of the fpu, int is still faster. unlike with 8 bit mcus, that have to break up the operation into a few, this 32 bit machine chews threw it in one shot. but im up to 13+ frames a second now
  15. its nekro time! so i made some progress on the electronics side of things. this was made possible by a couple of things. the first: i finally found an ili9341 library for the arduino due that works. so my lcd can now reliably output data. there was another thing but i forgot what it was. so i started working on a decompression algoritm in c (format four) for the arduino. this turned out to be a very easy thing. it was solid so i didnt mess around with it till now, i determined that it takes less than 150 microseconds to decode a block and send it to the screen. thats 5 frames/sec territory. i thought the float math would slow it down but apparently this little arm processor has some nards. as a fun little thing i might compare it against fixed point math to see if i can make it a little faster. next task was to build a state machine to handle serial commands and lcd operation. this hit a kind of a snag. at first i wrote this unpredicable mess. initially i wanted to minimize protocol overhead and decided i would cram data and command into a single byte and send them over serial. since i had about 6 3-bit commands, it meant that any errant peice of data could be mistaken for a command. that had to go. so i rewrote a 2 command system. the number of commands also went up slightly because of it. but i realized that only one command had to be fast, the one that sends data. configuring the state machine meant sending 2 bytes a pop. but thats usually done once. setting the insertion point would take 4 bytes, maybe i can get that down to 3 with a 3-byte command, or single byte commands to jump to pre-defined locations, like the starting corner or the beginning of a scan line. so to save some commands i made it so that the insertion point advances every time a block gets pushed through. after some debugging it worked fine in the terminal. i used my lua test application to dump all the block data and required commands to a file. initially i tried outputting it directly from the lua script, but there was some kind of issue with the way lua passis strings containing binary data, some control characters just dont go through, and in some cases i ended up with a lot of extra data that i couldnt explain. there should be 1200 19-byte blocks and about 32 1-byte commands to push each scan line and start the process. i tried dumping it to a file and never wound up with the 22832 byte size the whole frame should have been. i looked at the lua documentation and forgot to set the write mode to binary. derp. i was still not able to scan out over serial, but i loaded up realterm and dumped the file over serial, and everyones favorite little kitten (and now gargantuan 15-pound desk hog) lizzy popped up. much swearing at my bit of spaghetti code lua app ensued after that, but i never quite got it to work. it is still somewhat useful to convert images to the compressed format for now. ultimately i intend to write a compressor in c. but i really dont feel like digging out that gargantuan visual studio ide and ms's bloated libs. its one of those rare cases i envy linux users and their make files and their lovely gcc compiler. raspis cost a few bucks now, or as soon as production ramps up anyway. also considering trying to run the display directly on an esp8266 (though i dont think they have the gpio to run my camera module). im sure there are other dev boards, anything with fast wireless and an arm processor will be great. who knows what the future holds, for now heres some goodies. you notice that the image is mirrored on the screen, theres probibly a setting in the tft library to fix that.
  16. i dont think galactic colonization will come as a product of alcubierre drives, or orion drive generation/sleeper ships, on long voyages to distant starts. it will start off as a single colony close to home, that civilization will deplete its resources and send the next colony out.and humans will hop from rock to rock over the course of many generations. they will go anywhere where there is usable material and fuel for their reactors. out from the kuiper belt and into the space junk between stars. individual voyages would be less than a human life span and wont go far, and the generations that follows will go a little further. we could have a sizable portion of the galaxy colonized in as little as a million years.
  17. i think its a moment of inertia problem. the more the mass of a ship is distributed outward, the harder it is to turn. so you end up needing a lot more rcs thrust (and fuel) to maneuver. a good example is if you have ever had to carry a long 2x4. the piece of wood is easier to rotate about its long axis than the other 2 axes, and the reason is a lot of mass further out from the center. the same mass spins fine along the long axis because it is very close to the axis.
  18. i was thinking of having a lightweight unpressurized (my double hulled toroid design gives astronauts double protection against vacuum, so further protection build into the centrifuge is unnecessary) centrifuge on some kind of magnetic bearings or maglev track system (a magnetic system has the added bonus that you get a degree of shielding from charged particles) inside a pressure hull. spinning the whole ship would introduce g loads on a lot of parts and require more beefy structural members, increasing overall mass. instead of spinning a light weight composite room with a few astronauts inside. much of the life support equipment and consumables are actually mounted inside the static hull. there might be a service car that runs in a channel next to the centrifuge (shared with a counter-torque system) that can spin up and down to transfer consumables, empty septic and gray water and trash systems (to the recycler in the static hull), and allow crew transfer between the static hull and the centrifuge (for maintenance and other operations).
  19. i imagine a big double hulled toroid with an engine cluster at the hub. the inner hull would contain the habitation centrifuge, while the space between the inner and outer hull will be used for propellant, water and other consumables that can be used for rad shielding. if the hub contains a reactor, then ring of metallic shielding and perhaps the radiators, coolant reservoirs, or additional consumables surrounding the core could be use to protect the centrifuge. you dont need any shielding in front of or behind the reactor, and the space between the reactor and the habitable centrifuge also helps to reduce the radiation at the habitable section.
  20. i figured the forces were high, after all all your north poles face inward. magnets generally dont like that. its probibly why wb6 shorted out after just 3 shots. but 30 metric tons is kind of nuts. this is true but technically we can use anything up (but not including) iron and come out energy positive. obviously we are gonna start with the easy stuff. when we start running out of fuel for fusion reactors we will have more pressing problems, like all the stars dying.
  21. Nuke

    Vulkan API

    i tried to run some of the demos but i guess only one version of forceware supports the beta drivers, and id have to backtrack driver versions to try it out. i really dont want to do that. im sure a lot of people have the hardware to run vulkan, but a lot of game studios wont even touch it unless a large part of their intended demographic has support for the api. multiplatform engines (like unity and others) might be the first to support it, as they already have an abstraction layer in place to pick and choose apis. new cutting edge engines will definitely have support to be future proof. but uptake will be slow as it has always been. for example there are still some pretty impressive texture formats that my hardware supports (for years, i have obsolete rigs that supported them), but ive yet to see a commercial product use them (mobile devices are ironically ahead of pc in terms of texture formats, while pc is stuck with those 90's dxt formats for legacy support, phones use all kinds of cool formats, like astc, that look much better).
×
×
  • Create New...