bimm

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

102 Neutral

About bimm

  • Rank
    Newbie
  1. I thought it might be interesting for some to see an older system being programmed [in assembly]. It's a bit of a boring part at the moment (reading documents), but the goal is to create an MSX audio/music driver that is tracker friendly. Stream: [url="http://www.twitch.tv/mukunda_"]http://www.twitch.tv/mukunda_[/url] If I'm playing Diablo then check back later. :-)
  2. simple math problem

    Thanks a lot, this is much better than the code I shoveled into my shader... I didn't even notice that my figure was actually a triangle lol
  3. simple math problem

    unfortunately my math skill is a bit lacking I need to find the latitude and longitude of the intersection of a ray coming from the center of a sphere to the radius/surface. What I have right now is lat=atan(z,x) and lon=asin(y) (after normalization) Now this doesn't provide a very convincing sky-sphere, since usually you aren't in the core of the earth. What I want to do is move the origin of the ray upward closer to the surface. I guess this only changes the longitude, and it can be computed with a table. I just need a formula to convert angle a to b, [url="http://imageshack.us/photo/my-images/405/problem1a.png/"]http://imageshack.us.../problem1a.png/[/url] edit: and what is known is 'a' (or the actual ray), the radius of the sphere, and Y or height of the ray from the center of the circle
  4. I have around 4000 buffers that need to be drawn, and I change my shader uniform 'translation' value before each drawing. Should I just store the entire translation+position in the vertex position instead to avoid changing that uniform rapidly? (it would require a larger position datatype to hold the range)
  5. Just a couple questions that have been bugging me... I'm wondering what kind of impact each of these elements has on the GPU. Small vertex data, non 32/64-byte, does this have a significant performance impact? Some documents say to use 32 bytes but I don't know how up to date they are. I'm also manipulating/creating a lot of the vertex data so small vertexes would definitely help out the CPU side. Floats for data values. It seems a lot of examples/sources use floats as for the data values. Does using other data types for values have any significant slowdown? Any info or documents about these topics would be very helpful, thanks!
  6. I'm trying to use Autodesk's FBXSDK in my project. I know I can load vertex data from a 'mesh' but I'm wondering if this workflow is possible: Load my FBX model into a mesh instance frame loop: Set animation to X frame (with whatever animation API it has, still reading about it) Read transformed (by animation data) vertices directly from mesh instance into vertex buffer Render (animated) model (repeat) Is that how it can work? Or do I have to transform the vertices myself with data from the animation instance? Sidequestion: is the SDK still free for commercial purposes? (given I put a notice in my documents)
  7. I've been working on a new game for the past couple months. I've decided to blog the development progress, so people can see the game mature from scratch to finish. Check it out here!: [url="http://archubos.com/blog"]http://archubos.com/blog[/url] I promise to add more content and interesting posts over the weeks!