Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›2 »

That Turkey Story: Mar 30, 2003

SuperFurryAnimal posted:

I've been developing techniques for the realtime procedural animation of assorted creatures for my Ph.D. The idea is that all animation is driven by the creature's embodiment in the environment, taking a lot of insperation from AI, robotics and ethology.

Video from last year: http://www.youtube.com/watch?v=I1P_B65XW4I

Most of the work has concentrated on Spiders, although I'm currently extending the simulation to cover creatures of similar morphology (body close to ground, legs in parallel), such as insects and lizards.

That's absolutely amazing. Awesome job!

# ¿ Jun 12, 2008 01:41

Adbot: ADBOT LOVES YOU

# ¿ May 6, 2024 06:42

That Turkey Story: Mar 30, 2003

Lil' brim!

# ¿ Sep 23, 2008 21:33

That Turkey Story: Mar 30, 2003

numeric_atrophy posted:

My iPhone game is finally finished. First game ever. I feel all tingly.

Spaceballs
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=312145716&mt=8

Is that supposed to look like a butthole?

# ¿ Apr 18, 2009 00:54

That Turkey Story: Mar 30, 2003

Like an actual butthole where poop comes from.

# ¿ Apr 18, 2009 01:59

That Turkey Story: Mar 30, 2003

I like the post. Really cool post.

# ¿ Jul 6, 2009 04:14

That Turkey Story: Mar 30, 2003

Started fooling around with homebrew DS stuff today. Sup, Mandelbrot:

Takes a few seconds to render on the DS because I'm using software floating point, but still cool.

# ¿ Jan 4, 2010 12:12

That Turkey Story: Mar 30, 2003

tripwire posted:

Thats awesome. Do you have any pointers on how to get started with DS homebrew stuff like this? Even being able to see how you did the mandelbrot would be really interesting to me.

It's actually really, really simple. There's no OS and basic drawing to the screen is literally a matter of initializing a pointer to the location of the buffer and writing to it. Everything together ended up being only about 60 lines.

To get up and running all you need is devkitpro. I set up the ARM compiler in Code::Blocks and used Boost.GIL just because setting up Boost on DS seemed like a sick idea that I had to try. GIL has sample code for virtual image views that I just adapted slightly to handle the 5:5:5:1 rgba color format that the DS uses -- thanks to GIL, all that was necessary was applying a template metafunction to generate an appropriate pixel type which I used to make an image view directly to memory. C++/Boost owns.

Get used to not working with floating point though since there is no hardware support meaning operations on them are slow as hell. There is hardware support for fixed point operations, however, that you can access via library functions included in ndslib that comes with devkitpro. Avoid floats/doubles/long doubles since, again, they're going to be done in software.

# ¿ Jan 5, 2010 08:50

That Turkey Story: Mar 30, 2003

the wizards beard posted:

Wow, do you think the slow frame rate is because you using Boost? Seems like a lot of overhead for a machine with a 4mb memory.

There is little-to-no overhead for Boost. I'm not even linking to any prebuilt code. Like most Boost libraries, GIL is header only and all of the templates are only instantiated if they are used. Of what I used, everything is just interface wrappers that get compiled out entirely, which is how generic libraries should be. Making a virtual image view literally consists of creating storage on the stack for dimensions of the image and nothing more, the pixels are all lazily evaluated (virtual doesn't mean virtual functions, it means that the image isn't actually stored anywhere). Similarly, a GIL image view over memory just encapsulates a pointer to the start of the buffer, dimensions and stride -- thats it. Everything is entirely stack-based and the operations internally all just deal directly with unwrapped pointers and functions themselves end up inlined. The benefit is that GIL provides an essentially no-overhead layer of abstraction that lets you work with any combination of image types you can think of and provides a few basic algorithms that are instantiated specifically for the types you are dealing with when used. It is compiled-out entirely and yet it is generic enough to quickly drop in and easily work with the odd pixel format. That's why generic programming in C++ owns.

Mustach posted:

He blamed floating point in both of his posts and dedicated an entire paragraph to warning against the "slow as hell floating point."

Yeah, seriously. I do millions of floating point operations total for the whole image.

That Turkey Story fucked around with this message at 08:12 on Jan 6, 2010

# ¿ Jan 5, 2010 19:45

That Turkey Story: Mar 30, 2003

Vanadium posted:

In that case, would you mind posting the code?

http://codepaste.net/o48xau

# ¿ Jan 6, 2010 00:38

That Turkey Story: Mar 30, 2003

My current Nintendo DS project. Acquire!

Almost everything is done except for mergers involving more than 2 hotels and networking (and I need to make some better graphics).

# ¿ Mar 26, 2010 22:45

That Turkey Story: Mar 30, 2003

Factor Mystic posted:

Ah, I love Acquire. You're probably going to want to choose some more distinct colors for each of the stocks, right now they're all earth tones and sort of run together. Keep us updated

You mean the little hotel ID tiles in the bottom screen? I thought that as well when I first started off testing in an emulator, but on the DS screen itself the colors appear a lot more vibrant and distinct for some reason. Even between emulators (nocash and desmume) the colors are drastically different.

Edit: I will also be outlining the hotels eventually, I just haven't gotten around to it.

That Turkey Story fucked around with this message at 09:43 on Mar 28, 2010

# ¿ Mar 28, 2010 09:39

That Turkey Story: Mar 30, 2003

clockwork automaton posted:

So I participated in a 24-hour game coding competition (OSGCC) this weekend and me and my teammates got 1st with this DDR-clone done with ASCII art. Of course it was coded in D (because me and one of my teammates are insane) and we had one teammate that was entirely in charge of the music and the ASCII art (she did amazing).

Yeah, that's a narwhal. We had to incorporate 2 themes and ours were randomly picked to be narwhals and corn. Thus the random narwhals and corn absolutely everywhere.

https://www.youtube.com/watch?v=Fil-LXC9CRA

Okay, this rules.

# ¿ Oct 26, 2010 02:49

That Turkey Story: Mar 30, 2003

Okay, only a screenshot of code but it's cool if you're into generic programming. Over the past month or so I've been working on a couple of crazy preprocessor and template metaprogrammed libraries for generic programming and for automatically deducing function return types in C++. With them you can write concepts and concept maps, including auto concept maps, perform concept checking similar to BCCL, and even do concept-based overloading of function templates -- no more having to explicitly do tag-dispatching to simulate it in C++! You have to use very magical-looking macros but the end result is more concise code with less boiler-plate when, for instance, dispatching to different overloads based on which concept refinements certain arguments model. The example shows something akin to std::advance.

Click here for the full 1015x1172 image.

# ¿ Nov 28, 2010 18:23

That Turkey Story: Mar 30, 2003

ColdPie posted:

You used a bunch of big words, but to summarize, is this at all similar to the Concepts feature that didn't make it into C++0x?

Yes, it is that (or tries to be an extremely close approximation). Since we likely won't see direct language support for a long time as it's had to be cut from C++0x, and given how long standardization takes, a library is the best that can be done while still being portable between many compilers. At this point in time only GCC has all of the C++0x features necessary to make this library usable.

For an example concept definition, let's say you want to specify a concept that represents the base abstraction of an Iterator (the requirements are based on the requirements in the C++0x working draft at 24.2.2, page 816). With my library you'd use the following syntax, though I already provide this definition in a header you can include:

code:

BOOST_GENERIC_CONCEPT
( Iterator, ( X )
, ( using ( (CopyAssignable)( X ) )( (CopyConstructible)( X ) )
          ( (Destructible)( X ) )( (Swappable)( X ) )
  )
, ( if typedef ( std::iterator_traits< X >::difference_type )
               ( std::iterator_traits< X >::value_type )
               ( std::iterator_traits< X >::iterator_category )
               ( std::iterator_traits< X >::reference )
               ( std::iterator_traits< X >::pointer )
  )
, ( if ( is_signed< typename std::iterator_traits< X >::difference_type > )
       ( is_same< decltype( *std::declval< X >() )
                , typename std::iterator_traits< X >::reference
                >
       )
       ( is_same< decltype( ++(std::declval< X& >() )), X& > )
  )
)

Going through line-by-line, The first parameter specifies the name of the concept, "Iterator". The second parameter is a parameter list for the concept -- here we have 1 parameter, the type we wish to check if it's an iterator. We call this parameter X. I currently support concepts with any finite number of parameters.

The remaining parameters are optional to the macro and can even appear in any order (this is one reason why the libraries are so big -- I simulate named parameter passing in macros).

The "using" parameter is how you specify concept refinement. An Iterator is a refinement of CopyAssignable, CopyConstructible, Destructible, and Swappable (all of which I have defined in other files), meaning that it has the requirements of all of them combined and also specifies a relationship between them that may be used for, for instance, concept-based dispatch. As an example of that, if you have two simulated function template overloads using my Auto_Function library, one overload for "CopyConstructible" models and another for "Iterator", the Iterator one would be picked if you passed in an std::vector< int >::iterator since it would be a better match -- most importantly, it is NOT an ambiguous call even though it is both CopyConstructible and an Iterator. For that example there isn't much reason to write overloads like that, but for algorithms such as std::advance this is extremely important as you have to dispatch to different implementations inside of std::advance based on which kind of iterator your parameter models in order for it to be linear for InputIterators and constant time for RandomAccessIterators.

The "if typedef" parameter specifies that the parameters specified must exist and must be types. Here we are checking that it has the appropriate iterator_traits defined, as required by the standard.

The "if" parameter specifies that those conditions must hold true. First we check that difference_type is a signed type. Then we verify that dereferencing and prefix operator++ are defined and each have the correct return type.

The above is currently how I have Iterator implemented, however, it will get even somewhat simpler very soon. Right now I'm creating "for" and "for typedef" parameter types that let you specify names for commonly used typedefs and objects. This means that you wouldn't have to fully specify things like typename iterator_traits< X >::difference_type every single time you use them, and you wouldn't have to use std::declval at all. This makes the concept definitions more concise and also makes it possible for them to look very similar to the tables in the standard -- even using the same names for given objects and types.

For an example of how RandomAccessIterator (C++0x working draft reference 24.2.7, page 820) would look once I finish implementing "for" and "for typedef". I encourage you to compare the table in the working draft with the following code. The single letter names are used because they are what are used in the standard:

code:

BOOST_GENERIC_CONCEPT
( RandomAccessIterator, ( X )
, ( using ( (BidirectionalIterator)( X ) ) )
, ( for typedef ( (std::iterator_traits< X >) traits )
                ( (traits::difference_type) difference_type )
                ( (traits::reference) reference )
  )
, ( for ( (X) r, a, b )
        ( (difference_type) n )
  )
, ( if ( is_same< decltype( r += n ), X& > )
       ( is_same< decltype( a + n ), X > )
       ( is_same< decltype( n + a ), X > )
       ( is_same< decltype( r -= n ), X& > )
       ( is_same< decltype( a - n ), X > )
       ( is_same< decltype( b - a ), difference_type > )
       ( is_convertible< decltype( a[n] ), reference > )
       ( is_convertible< decltype( a < b ), bool > )
       ( is_convertible< decltype( a > b ), bool > )
       ( is_convertible< decltype( a >= b ), bool > )
       ( is_convertible< decltype( a <= b ), bool > )
  )
)

The above should be very self-documenting and corresponds directly to the standard. At the moment, I have RandomAccessIterator implemented using std::declval, which is fine, but much less concise than what you see above. I won't post the code unless someone really wants to see it, but needless to say it's hairy. All of those "a", "b", "r" and "n" are std::declval calls, "difference_type" and "reference" are always referenced via iterator_traits, and "n" also has to refer to the difference_type via iterator_traits to pass it to std::declval. It's ugly, but works.

The concepts I've shown don't declare associated types or functions since there's no such thing as them with respect to the standard in the concept map sense (as concept maps in the standard don't exist other than "sort of" via traits classes). Of course, direct associated types and functions will be supported eventually and will be able to be mapped to, but I want to be able to support all of the concepts in the standard first. It's also a much harder facility to implement in macros, mostly do to me having to come up with a textual representation to be able to parse and translate with the C++ preprocessor.

Now how do you write concept maps? Since I don't yet support associated functions and types, they have very sparse definitions. The following is an "auto" concept map (similar to auto concepts that would have been in C++0x). It specifies that all types are automatically considered RandomAccessIterators if they meet the requirements specified in the concept definition. Right now, you have to provide a name for the concept map, but I may be able to remove that. Either way, it will likely be optional since I can use it to provide better error reporting.

code:

BOOST_GENERIC_AUTO_CONCEPT_MAP
( ( (class) T )
, auto_random_access_iterator_map
, ( boost::generic::std_concept::RandomAccessIterator ), ( T )
)

This is just an example though it is what I currently do in test code. Iterators should not be auto for various reasons. The big show-stopper here for why they literally can't be auto is that iterator_traits has a default definition that looks for nested types. Therefore, if you ever were to check which concepts a type that did not have those nested types modeled (for instance, "int"), you would get an error during the auto concept check specified above since the instantiation of the default definition of iterator_traits would not be valid for that type and SFINAE can be of no help for such a situtation.

The screenshot linked in my other post shows how you can use the concepts when writing something like std::advance. You may be able to figure out what it's doing by reading it, but I can explain it if necessary.

That Turkey Story fucked around with this message at 23:17 on Nov 30, 2010

# ¿ Nov 30, 2010 00:09

That Turkey Story: Mar 30, 2003

I forgot one more big plus. Improved error reporting. When you write templates you generally expect your parameter types to models of particular concepts (I.E. std::sort requires random access iterators and if you provide something else you'd get a gross kaboom). The Boost Concept Check library provides some help in this case, but my library should be able to go one step further, though admittedly I haven't gotten to that step yet. Because of the nature of the concept definitions as macros and because I do all of my concept checking via SFINAE as opposed to compiler errors, I am able to provide exact error messages as to what a user did wrong.

For instance:

code:

BOOST_GENERIC_ASSERT_CONCEPT_IS_MODELED_BY( (RandomAccessIterator), std::list< int >::iterator )

would be able to give a clean error via a static_assert that says something along the lines of:

RandomAccessIterator is not modeled by ( std::list< int >::iterator )

Further, for auto concept maps, I could even give a message that says exactly why it does not model that concept (again, Iterators shouldn't have fully auto concept maps, I'm just using them for the sake of example):

code:

BOOST_GENERIC_DETAILED_ASSERT_CONCEPT_IS_MODELED_BY( (RandomAccessIterator), std::list< int >::iterator )

The above could, in theory, produce an error message such as the following:

RandomAccessIterator is not modeled because the arguments do not satisfy the condition in auto_random_access_iterator_map ( if ( is_same< decltype( r += n ), X& > ) )

After I implement "for" and "for" typedef, the above types of error reporting are only a couple steps down on my list of features to implement next.

That Turkey Story fucked around with this message at 00:33 on Nov 30, 2010

# ¿ Nov 30, 2010 00:30

That Turkey Story: Mar 30, 2003

Mustach posted:

I was expecting a hideous macro mess, but this is very readable. Awesome work!

Thanks. I've put a lot more time than I originally had expected I would into making it usable and to have it look as readable as possible. During development I've gotten more intimate with preprocessor metaprogramming and came up with more strange preprocessor and template hacks than I've ever wanted to. For instance, each of those "if" parameters in the first example can actually be either a valid mpl integral constant type or a bool value. A user may provide either or and mix and match them in the same invocation. The way I do it is I rely on the fact that

bool ( something )

is a function type that returns bool and takes a "something" when "something" is a type, whereas it is a cast to a bool when "something" is a value. So what the macro does internally is effectively:

decltype( compile_time_bool< bool( something ) >() )

where "compile_time_bool" is a function template overloaded as such:

code:

template< bool Value >
boost::mpl::bool_< Value > compile_time_bool();

template< class FunctionType >
struct compile_time_bool_impl;

template< class ParamType >
struct compile_time_bool_impl< bool( ParamType ) > : ParamType {};

template< class FunctionType >
typename compile_time_bool_impl< FunctiontionType >::type compile_time_bool();

It's one of those crazy things that I don't think anyone would appreciate unless they really thought about how it could be implemented. The library is littered with those kinds of quirky, subtle tricks that hopefully improve usability.

Over the past couple of days though, I've considering changing design a bit. I realized that if I'm careful, I can make it so that the implementation of my macro could be updated to expand out to hypothetical C++1x concepts whenever they come to be. Consider if I change my design to take the following approach:

code:

BOOST_GENERIC_CONCEPT
( ( RandomAccessIterator, ( (class) X ) )
, ( using ( (BidirectionalIterator)( X ) ) )
, ( typename ( (std::iterator_traits< X >::difference_type) difference_type )
             ( (std::iterator_traits< X >::value_type) valur_type)
             ( (std::iterator_traits< X >::iterator_category) iterator_category )
             ( (std::iterator_traits< X >::reference) reference )
             ( (std::iterator_traits< X >::pointer) pointer )
  )
, ( public ( operator minus,      ( X, X ),               difference_type )
           ( operator index,      ( X, difference_type ), reference )
           ( operator plus,       ( X, difference_type ), X )
           ( operator plus,       ( difference_type, X ), X )
           ( operator plus_eq,    ( X, difference_type ), X& )
           ( operator minus_eq,   ( X, difference_type ), X& )
           ( operator less,       ( X, X ),               bool )
           ( operator less_eq,    ( X, X ),               bool )
           ( operator greater,    ( X, X ),               bool )
           ( operator greater_eq, ( X, X ),               bool )
           ( operator less,       ( X, X ),               bool )
  )
)

The named operators are necessary as opposed to +, -, etc. due how C++ preprocessor concatenation works. All operators end up having to be handled with that special syntax, with the sole exception of operator ().

I'm not sure I like how this looks when compared to my current code, but in theory, this design should be just as capable only I would be able to optionally translate it during preprocessing to what C++0x concepts used to look like in the last working paper. That way, once concepts eventually do become standard (some standard after C++0x of course), or at least supported by more compilers as extensions, code written using the library would most-likely be able to just swap out the back-end of my macro and be able to use their compiler's concept implementation underneath the hood. It's unfortunate I realized this so late in development since I already put so much work into the current design. I may just continue on as I have been for now and implement the above design in a manner that uses my current macro in its implementation.

# ¿ Dec 2, 2010 08:23

That Turkey Story: Mar 30, 2003

Mustach posted:

I was expecting a hideous macro mess, but this is very readable. Awesome work!

Alright, I got "for", "for typedef", and the assert working and I'm really proud of it so check it out! The macro temporarily has a long name because I can't think of a more concise one -- what it does is it checks all of the superficial requirements of the concept, in other words, it will only produce error if the conditions in the concept fail, even if a concept map hasn't been written for the type. This ends up being useful in practice because things like iterators should not be auto concepts, however, since iterators up until now have been written without C++ concept support, you likely just want to check requirements rather than whether or not a programmer explicitly wrote a concept map using my library. There, of course, are asserts that check the latter as well.

Here's an example with a basic but contrived binary concept, just to show things off. Note that with the following code the first error, which states that the assertion failed, points to the line where the user invoked the macro. This is where they would most-likely expect to see it. The errors that follow point to the concept definition and tell the user exactly which conditions failed and doesn't mention any that passed. This makes it simple for the programmer to see exactly what went wrong in the context of the concept itself.

The simplicity of the definition and errors hides just how complicated this library actually is.

...just don't ever try to read the code that the concept macro generates

Edit: Now an even more concise error message

That Turkey Story fucked around with this message at 17:13 on Dec 13, 2010

# ¿ Dec 10, 2010 22:04

That Turkey Story: Mar 30, 2003

Lone_Strider posted:

I've been keeping a personal database of scores for a game called beatmaniaIIDX since about 2004, and I wrote a windows mobile client that would sync up with it.

Looks great. I haven't played a lot of iidx, but I used to play way too much Pop'n Music. It's been a while but I remember Pop'n Navy, which was for keeping track of Pop'n Music scores and, after searching, there apparently was one for iidx as well (both of which closed down but were resurrected as "Solid State Squad"). Is this related at all to that?

# ¿ Dec 16, 2010 00:18

That Turkey Story: Mar 30, 2003

HappyHippo posted:

Started working on this again. It's a Civilization clone, but on an actual globe. So far I've mostly just been working on making the globe, but there are some units that move and cities. No combat yet.

Is that really a full globe or does it stop at some point? How do you handle the fact that you can't really tessellate hexes over a sphere? Is it more like a warped cylinder or something that cuts off before the poles?

# ¿ Dec 16, 2010 02:15

That Turkey Story: Mar 30, 2003

antimatter posted:

It is probably a complete sphere, and the trick is that you can sort of tessellate the hexagons over a sphere but you need to have a few points that are pentagons. I forgot the exact number but its not going to be 100% hexagons.

Well, yeah, you can do that without too much trouble for the graphic, but for a game that's more than a little odd, not to mention that it makes the underlying graph structure more complicated. A graph corresponding to a traditional hex grid is pretty much just as easy to implement as that of a grid of squares. The vertices and edges of the graph are represented implicitly and you can store all your tile data very easily in an array, knowing exactly which vertex it corresponds to by the index. Absolutely no information needs to be explicitly stored in memory about the graph structure (other than width) since you can trivially calculate the adjacency of vertices in constant time. All operations are both easy to implement and very efficient.

I'm sure it's possible to figure out some similar but complicated way to do something like this efficiently with an odd grouping of the irregular hexes mixed with other polygons, but it seems, at least to me, to be perhaps needlessly complicated, at least from what little I know about it. Also, the more irregular the polygons get and the more you use polygons with differing numbers of sides, you get some strange and unintuitive results concerning the represented distance between tiles, which is definitely not something that is desirable for a game. For a grid of squares or regular hexes you generally don't have such problems since the theoretical distance between any two adjacent vertices is constant and the optimal routes between two tiles are fairly simple to calculate.

Still, I really like this idea of the fully tiled sphere, I just don't immediately see how it would work well for a civ-like game for the above reasons. It looks like he's done it to some extent, but there are definitely some tough trade-offs that he hasn't mentioned.

# ¿ Dec 16, 2010 03:58

That Turkey Story: Mar 30, 2003

antimatter posted:

Yeah, but the thing is its a fixed amount of pentagon, something like 12 and you end up with thousands and thousands of hexagons, so its not too bad for most part imho.

Thats 20 hexagons to 12 pentagons, which is hardly a small amount of pentagons. I don't immediately see what you can do to simply increase the amount of [regular] hexagons, unless you start using more and more irregular polygons or polygons with different numbers of sides and/or a more warped approximation of a sphere. The more deformed the polygons get, the more you defeat whole purpose of using regular hexes in a game to begin with.

# ¿ Dec 16, 2010 14:44

That Turkey Story: Mar 30, 2003

HappyHippo posted:

There is indeed some distortion of the hexes, especially near the pentagons, but it isn't particularly noticeable. In terms of gameplay, I'm just counting on those 12 pentagons to not have a big effect on a world that large.

Interesting. I always wanted to play some kind of a turn-based, tiled game on a globe. If you make some more progress with controlling units I'd like to try it out.

antimatter posted:

You can subdivide hexagons into smaller set of hexagons you know.

Lets see you do this with an exact fit and using regular hexes. As was said, there is, by necessity, distortion.

# ¿ Dec 16, 2010 17:00

That Turkey Story: Mar 30, 2003

Jick Magger posted:

(yay I finally have something to post here)

I spent a while after I graduated putting together a fridge magnet poetry type thing. Basically, it provides you with all the different parts of grammar, and you use them to produce instant Dada art.
Now I just need to figure out why it should exist...

https://www.mutantdog.com

Psychobabble/Farragomate/Pseudobabble has been around for a while in various clones and is a great game but has been plagued by poor implementation. The general idea is that you are in a room with 10 or so people. In each round, everyone is given a similar word list. The players make a sentence and then at the end of the round, the same people vote for the best sentence (you can't vote for your own). Each vote your sentence receives gets you 1 point. If you vote for the most popular sentence you get one point. You keep going until one person reaches something like 30 points. You could always make something similar to this. The current incarnation is very buggy so if you could do a better job that'd be great.

# ¿ Mar 5, 2011 00:13

That Turkey Story: Mar 30, 2003

Game logic is rarely a bottleneck even for big budget modern games -- many of which also use languages such as lua or python for those aspects of their game (avoids recompiles, and much easier for designers to work with if they have to).

Unless you're writing the next Civilization, you're probably not going to have to worry much about your game logic impacting performance.

# ¿ Mar 19, 2011 17:12

That Turkey Story: Mar 30, 2003

At the end of last year, I posted in this thread about a C++ library I was working on that emulated the postponed C++0x concepts features. Back in May of this year, I gave a talk on this library at BoostCon and that talk is now online. This was my first time presenting for an hour and a half straight, so I was a bit nervous in the first few minutes, but it picks up.

Anyway, you can watch the talk here and the slides are here.

# ¿ Jun 11, 2011 01:24

That Turkey Story: Mar 30, 2003

Otto Skorzeny posted:

I can't watch tonight because I'm goin hiking with a friend tomorrow and she wants to be on the road by five in the loving morning but: I'm looking forward to seeing how your project turned out, and I hope you appear in a star trek uniform like you did in that other video

I did, and I whisper catchphrases into the microphone every once in a while if you listen carefully. There's also a single frame of goatse in each slide transition.

# ¿ Jun 11, 2011 08:00

That Turkey Story: Mar 30, 2003

All of the questions at the end got cut off, which is unfortunate. IIRC, I went into some of how the preprocessing works behind the scenes.

# ¿ Jun 11, 2011 17:04

That Turkey Story: Mar 30, 2003

Plorkyeran posted:

This is pretty awesome (both the project and the talk once you relaxed).

Thanks. Concepts own. :banjo:

# ¿ Jun 15, 2011 17:09

That Turkey Story: Mar 30, 2003

LOLLERZ posted:

Oh my god. This image by itself is a hilarious joke.

Yeah, was thinking the same thing. At first I thought it was a fakepost.

# ¿ Aug 6, 2011 07:48

That Turkey Story: Mar 30, 2003

What if I'm binary-curious?

# ¿ Oct 7, 2011 01:21

That Turkey Story: Mar 30, 2003

ufarn posted:

Do you know about VexFlow?

This is actually really cool. If there were some way to export from Finale or Sibelius it would be amazing, though it looks as though there is a long way to go before it gets powerful enough to represent the same kind of stuff that those editors can.

# ¿ Feb 16, 2012 03:58

That Turkey Story: Mar 30, 2003

Thermopyle posted:

I think these are great.

How come the water in the glass looks like it's wider than the glass itself? My first thought was that the water, instead of stopping at the interior surface of the glass was stopping at the exterior surface, but on looking closer it certainly seems it comes a little bit further than that...

It's magic, you idiot.

# ¿ Apr 12, 2012 21:29

That Turkey Story: Mar 30, 2003

Sir Davey posted:

As a semester project, I have to improve the performance of an already built (in-house) Xylophone playing robot! This is by far the most awesome thing I've ever got to play with.
https://www.youtube.com/watch?v=mnRZ_Pj5k5Q

This is just my first test. You can't see in the video but it has 2 arms! I'll keep this topic updated once I get it to actually play something interesting

Don't mind the terrible noise, it's not coming from my robot. There's some construction in my lab right now and it's driving me crazy.

Whats with the picture of the flabby dude in the background???

# ¿ Mar 21, 2013 20:59

That Turkey Story: Mar 30, 2003

lord funk posted:

I'd like to voice my opinion that dials are a terrible interface for a mouse / touch screen. The best they come are the ones that are really just invisible-vertical-sliders (i.e., they go up and down with vertical touch movement and nothing else). But I cringe when I see you moving in a C-shape just to start the dial turning.

Seconding this. Dials are always a little weird in software. They just don't translate over very well.

# ¿ May 24, 2013 06:03

That Turkey Story: Mar 30, 2003

Orzo posted:

Had a little fun this weekend. My artist is tied up for a little bit so this looks goofy as hell without new animations. But here's a video of picking poo poo up and throwing it in Super Obelisk! Also enjoy the LTTP-ripped sounds.

https://www.youtube.com/watch?v=UAcItUDTcZc&hd=1

What are you going to be using for music and sound effects in the completed game? Is the audio going to be chiptuney, do you have a musician, etc.?

# ¿ Jul 6, 2013 23:16

That Turkey Story: Mar 30, 2003

Seven Round Things posted:

I see. It was less the embedded part and more the real-time part that surprised me- C++ encourages exceptions, dynamic memory allocation, etc which make for nondeterministic timing.

As someone who does the vast majority of his coding in C++, this isn't really true. C++ supports exceptions and dynamic memory allocation, but they're not encouraged (as in, you still only use them when necessary, like anything else). Writing something in C++ as opposed to C shouldn't change what data you're dynamically allocating and what data you're not dynamically allocating, and similarly, using C++ as opposed to C shouldn't imply that you all of a sudden have more exceptional behavior (that would certainly be a scary thought).

In other words, in C++ you should still minimize dynamic memory allocation and aim to have operations that do not have exceptional behavior, just like in C, and this is true whether you're doing embedded work or not.

# ¿ Jul 27, 2013 01:49

That Turkey Story: Mar 30, 2003

Sir Davey posted:

Xylobot is now a virtuoso. Thank you all for your support and feedback. I have a few other videos up my sleeves, so make sure to subscribe!

https://www.youtube.com/watch?v=cpeOZfV-MII&hd=1

Loving this. How dynamic is it? Does it just have a different midi track for each arm or something and is smart enough to perform, assuming the tracks are feasible? I want one :|

# ¿ Sep 5, 2013 17:20

That Turkey Story: Mar 30, 2003

clockwork automaton posted:

Not so much of a screenshot as a video of the UI in action for automatically generating star wars gifs.

Okay, this is hilarious. I want it for every show and movie.

# ¿ Oct 2, 2013 06:04

That Turkey Story: Mar 30, 2003

Rottbott posted:

I don't believe that's true. If you're using modern C++, and you at least know enough to use smart pointers and not call new or delete, it's more difficult to get it wrong than right.

You still get resource leaks in garbage collected languages anyway.

Seconding both of these points. If you're programming in modern C++, you're generally not manually managing memory. This has been true for a while, but is even more the case since C++11. In fact, I'd argue that it's much easier to do proper resource management in modern C++ than in a language such as Java or C#.

# ¿ Feb 22, 2014 07:29

Adbot: ADBOT LOVES YOU

# ¿ May 6, 2024 06:42

That Turkey Story: Mar 30, 2003

Shalinor posted:

This just isn't true. There is no C++11 magic that would ever make me let a junior engineer within a mile of a DirectX/OpenGL texture. They are SO easy to leak.

Huh? It's been true since well before C++11. There are plenty of smart pointer implementations out there that will work fine with DirectX, and all of COM, even if someone doesn't understand how to make one on their own. In fact, Microsoft themselves provided their own smart pointer types for COM since the 90s (although I personally wouldn't recommend them now).

That said, with Boost, even making one on your own is extremely trivial -- just define intrusive_ptr_add_ref and intrusive_ptr_release to call AddRef and Release respectively (each a one-liner) and use Intrusive Ptr. You are done in something like 5 lines of code and you now have a smart pointer for all of your COM objects, not just for textures, and the code is general enough to be used for any number of projects.

Beyond that, the determinism of RAII on the C++ side of things also makes it so that your resources are automatically cleaned up once you're done with them, including in the face of exceptions and without requiring additional effort (I.E. no need for C# using statements). This is true not just for memory but for any resource and is generally not the case in Java or C#. Herb Sutter has a now 10-year-old post about this that is still true today. It uses C++/CLI but the example is true regardless.

It's easy to convince people that superficially garbage collection makes resource management a thing of the past, but it's simply not true, especially given the language designs of Java and C# in relation to how they deal with garbage collection.

Shalinor posted:

You guys are also brushing over the development speed issue. I get that you like C (I used to be that way too - giant AAA codebase), but the rate at which you can develop with C# or Java is absurdly faster than what you can generally do with C++.

C++ is very different from C. I don't think anyone is recommending C here. I also simply disagree with the statement that you can develop in C# or Java "absurdly faster" than in C++. Perhaps it's the case that you can get simple apps going in a dynamically typed language such as Python faster than something like C++, Java, or C#, but I have extreme doubts that given a skilled programmer in C++, Java, and C#, that any of those three would march along remarkably faster or slower than the other in the general case. If you think that GC in Java or C# is really saving you tons of programming time and/or making your program more correct, then I can't imagine that you are anything but behind the times in the C++ world by 10-15 years. It is extremely rare that a person has to touch new or delete in C++, and properly handling resource clean up, especially when exceptions can be thrown, is also more trivial in C++ than the other languages that have been mentioned.

# ¿ Feb 22, 2014 23:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›2 »