I'm sure it will get some when I add a new feature. It always does...
The transmission speed depends on bandwidth (in MHz).
Our game finally has shown up in the Windows App store. We've worked really hard the past 6 weeks making it.
It's called Inkarus. You can find it by either searching, or looking under Games>New Releases (Note: you have to be running RTM, which hits MSDN today). I'd be really grateful if you could let me know what you think about it. Here's some screenshots:
If anyone is interested, I'll write a bit regarding the tech behind the game, and some of the challenges we encountered working with WinRT. For now, the basic overview of how our engine works is like this:
I would also be willing to share some code if anyone is interested.
If not the log should reveal to me what's wrong.
Would it be possible to use C++ in the windows app store?
Weapons kinda work a la NES LoZ.
Enemies die now.
Do I have to use Direct3D?
Will I really have to maintain two rendering engines if I use Direct3D?
Maybe somebody could have OOGL map to D3D?
Me and Perl has been fucking around in computercraft for a while now. Decided to write a C# http server that gives you an array of pictures converted into ASCII art. Then turn that into an animation in computercraft.
Still working on getting the image to be sharper. It's really hard to see what's going on sometimes.
Makes it really easy to have backwards-compatibility I guess...
Yeah it just instantly seg-faults for me.
Also, why the fuck are you dynamically linking everything? For fuck's sake, GLFW is only 47.5 KB.
Computercraft is really rad, though. I like using it for everything possible on servers that have it.
Oh man 1.4 makes it even more rad
I'm dynamically linking because it's far easier. Attempting to statically link caused tons of problems that I'm not willing to fix when it's such an early game prototype and I don't even use windows.
In the future I'll look into static linking, but right now I'll work on adding old opengl support. Thanks for the feedback!
I had one chance to look at metrostyle then visual studio broke. so its likely that im missing something obvious.
I should also add that I don't develop 3d games or applications. I really get frustrated though when people get their panties in a bunch when a company chooses Dx over OpenGL. A lot of people don't realize that the market (Windows + Xbox) is in favor for Dx and is usually the most cost-effective solution. However, If I was an indie developer who was making a new game tomorrow, I would choose OpenGL purely because I would be able to get more sales.
Practically, that means you'd be likely to get your mobile games easily ported on PS3 or something
(Of course, if you don't use many non-ES functions the porting of the graphics code is gonna be relatively simple)
Currently working on an API wrapper I'm calling "Vanillin". It exposes the standard Lua C API to binary modules written for GMod by implementing all of their functions using the GMod C API. So far, it's about 95% working, and its useage is literally drop-in. It takes the form of a static library called "lua51.lib", and during your build process, you just link against that instead of the Lua 5.1 DLL's import library (also called "lua51.lib") - there's no changes to the source code of any of these programs necessary, just need to be re-linked and renamed.
This makes most of the hundreds of already-written binary modules for Lua available for Garry's Mod, and more importantly for the large multi-person project I've been working on, means my team and I don't have to write separate versions of our binary modules for Garry's Mod and for the rest of the Lua Universe. Plus it's just nicer to be able to write with a more sane, consistent, and well-documented API that we have experience working with.
Here are some screenshots of the primary things I've been testing it with. First up, LPeg, a kind of advanced pattern-matching library that takes after SNOBOL:
Here's LuaXInput, a module I wrote myself for my large team project; it is one of the sub-modules of a larger LuaGameInput library, one of my personal projects:
Here are the MD5 and DES56 libraries, part of the Kepler Project:
And finally, here's LuaSocket, which is currently only mostly working...the TCP stuff seems fine but http.request() is crashing me:
The library implements all of the Lua C API's functions but does not necessarily support all of them...things like lua_setallocf() or lua_setpanic() will merely trigger an error, for obvious reasons. But through much effort and reverse-engineering, it fully and correctly supports things like strings with embedded nuls (both pushing and retrieving), lua_getstack() and lua_getinfo(), full userdata works correctly, including setting arbitrary metatables on it and correct support for __gc metamethods...it's been a lot of effort and I've spent nearly three months on this all told, but the gains have been well worth it.
With the changes to the API coming in GMod 13, it's delayed progress by about two weeks, but when it's all finished, I'll release it to the public. I can imagine quite a few people will be able to get a lot of use out of it.