We're offering banner ads on our site from just $5!
KhatharrMember Since 24 Apr 2010
Offline Last Active Dec 13 2014 06:42 PM
- Group Crossbones+
- Active Posts 1,109
- Profile Views 8,779
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by Khatharr on 05 January 2013 - 11:31 PM
Can you post an image showing the kind of distortion you're getting?
Posted by Khatharr on 04 January 2013 - 10:45 PM
OpenGL Super-Bible (Fifth Edition) however the Author seemed like a very Arrogant developer.I lolled.
Are you looking for GLSL info or info about how the pipeline itself works?
OGL had this buried in their site:
Posted by Khatharr on 04 January 2013 - 06:05 PM
Design comes first. Build your design from the top down (in your head or on paper) and then start writing the code that will implement that design. Obviously you can't test much until you have that component built from the bottom up, so I usually start from the bottom and build a system outside of the main project, test it thoroughly and then import it once I'm confident that it's working.
You should know at least the general concept of how an API is used and it's a good idea to flip through the docs and see what all it offers, but trying to memorize the whole thing would be silly. Just use the documentation as a reference and you'll usually automatically memorize the stuff you use the most.
About linux IDEs... vi? O wait... lol I dunno. I only use bash on emulators. I'm sure there's some good ones though.
Posted by Khatharr on 03 January 2013 - 04:56 PM
Posted by Khatharr on 02 January 2013 - 08:05 PM
Posted by Khatharr on 02 January 2013 - 06:31 PM
Posted by Khatharr on 01 January 2013 - 04:44 PM
You just throw player into some strange world.
I tryed to fight dogs. Then i saw some stuff on the ground.
Was chased by sceletons, run through upper door, see coast, pick stick, pick stick, run back - different place.
Same door - different place. And i'm dead. I love it, no jokes.
Almost sounds like 6 Days a Sacrifice, lol. Let's have a looksie...
Amassed an army of stray cats.
Acquired flamethrowers and discovered the OPness of the mighty BRANCH.
Defeated the restless dead.
Some problems I saw:
* Seems like pets wait for you to take damage before they defend you. I had like 4 HP and my army of cats would not attack the enemy because I had to run away lest I take any damage.
* WTH is going on with the timer?
* My inventory vanished consistently. I need a place where I can safely store more branches.
* Is the crafting system implemented yet? I dunno if that was just my inventory vanishing or if the system isn't there yet.
* I eventually ended up going up a staircase that somehow led underwater. I could not move and I seemed to be offscreen. There was a label on the top bar that said 'oxygen:' but there was no accompanying display.
It's fun to play with. Feels fast-paced without forcing you to play fast-paced and the exploratory "Gee, what's in THIS room? OMGOMGOMGOMG" style is something I miss from retro days.
Posted by Khatharr on 01 January 2013 - 08:59 AM
Posted by Khatharr on 31 December 2012 - 11:02 AM
C# supports DirectX, though if you disliked Java I'll warn you that C# is basically Microsoft's C-flavored answer to Java. YMMV
SDL has a C# flavor as well as C/C++, if you're interested in checking that out. It's really up to you to decide what you like. There's nothing wrong with SDL if you just want to make games with minimal fuss.
Posted by Khatharr on 31 December 2012 - 09:05 AM
You don't need the professional version - the express version is perfectly fine for commercial projects, and isn't limited in the restraining ways most software 'express' versions usually are.
I already have Microsoft Visual Studio Professional 2010 and to my knowledge you are not allowed to release games with Visual Studio Express. At times I worked for a MMORPG Project as 3D developer and everyone was obliged to use Visual Studio Professional or higher because the licenses.
There are no such restrictions. It would be silly, since any identifying metadata in the binaries could easily be ripped (or you could just make the thing with VS and compile it externally).
Posted by Khatharr on 30 December 2012 - 11:40 PM
Is cache management, like flushing a specific variable, is that manual?
Depending on the platform. You shouldn't have to mess with it in Windows, for instance. Platforms where it's useful will generally have API functions for managing it. It's only necessary when you have DMA going on and you have a situation where a DMA device may want to use memory that's cached on the CPU. It's actually quite rare, even in those situations. I think I only ever used it for the texture swizzle function and the texture hue-change function on aforementioned device. I just had to put a writeback call at the end of those functions and everything worked fine.
Interrupts can be signaled from asm. The instruction is INT on x86. http://pdos.csail.mit.edu/6.828/2004/readings/i386/s02_06.htm
(Edit - If you pick a fight with the thread scheduler the skeleton man will eat you.)
With the virtual memory model programs are more or less compiled as though they have exclusive access to the machine. The thread scheduler interacts with them from the outside. It's sort of like an emulator save-state. If you have the register states recorded and the memory recorded then you can restore both and resume execution as if there had been no interruption. VMM allows this because it can easily swap out pages for different processes, so each process basically has its own memory within the span of real-address-mode memory (or the swap file, depending on memory conditions). Since the stack for a thread is stored in that thread's stack page the register states can be pushed to that stack and then the stack page can be swapped to that of the next thread and the registers popped. This restores both the memory and the register states of the upcoming thread, so it continues as if nothing had ever happened.
When a PC boots it has a specific location that it looks to, usually on the primary disk volume, to find a startup module. The BIOS handles getting everything out of bed and then does basic loading to get the ball rolling. After that the startup module loads the OS and everything snowballs into place. On other platforms (like REDACTED that I was mentioning) the platform only runs one program at a time and the OS is just the first program to start. When it wants to run a program it places the path of the program in a specific place in memory then does a sort of soft-boot and the indicated program gets control of more or less the whole device.
Running an exe, the Windows loader does some pretty interesting black magic to map the different parts of the exe file into memory. The 'entry point' is calculated based on some values in structs near the beginning of the exe file. It's a pretty horrific mess in there TBH. You can read some about it here, but it may make you want to claw your eyes out. Basically the exe includes information about how big of a stack it needs and how big of a heap, etc. The loader gets it the pages it needs and then just sets eip to the entry point and lets it do what it wants. Sometimes it has to fiddle with some relative addresses within the file image in memory first, but VMM can usually eliminate that.
Just explain to me how I would, in assembly, instruct the computer to carry out two different threads at once.
How I would say something basic like "do A, B, and C in seperate caches. when you've done A and B, do D."
That's more basic concurrency than threading. You'd mean 'cores' or possibly 'fibers' there rather than 'caches'. This is actually a better concurrency model than threading in many cases.
I'd really like to see what you're talking about implemented in C++, though I hear rumors that some compilers have custom features for it.
Starting an actual thread in ASM is no different than doing so in C/C++. You have to invoke the operating system's functions for it. I think what you may want in this situation is just a task queue that feeds into more than one thread for execution, but I suspect that you may not get the results you're looking for. The thing about the Windows thread scheduler is that Windows usually has a pretty large number of threads running all over the place. It's not just the program in the foreground that's getting scheduled. The kernel needs to do work, programs in the background are doing work, etc, etc. So even if you split up work using threads you're not really getting pure concurrency since those threads will basically execute when they damn well please. Your work won't necessarily be paralleled and you'll probably end up waiting on results when you don't need to.
In other words, you may be a little ahead of the state of the art there, but people are working on it. If anyone knows about these rumored compilers that offer keywords for concurrency I'd like to know about them as well.
Posted by Khatharr on 30 December 2012 - 05:11 PM
I think L.Spiro wrote a nice article about it... Hang on a sec...
Yeah, here we go. I was looking over this while I was fiddling with my scene manager a while ago.
As for different stages/levels you can break them into data units (the map and resources, etc required for that stage) and then have your map state/scene load the data unit, run with that data until you move to another one, then just unload the current one and load the new one.
This forum formatting bug is killing me... -.-
Posted by Khatharr on 30 December 2012 - 04:08 PM
The idea being that reducing work by having good structure is very nearly always better than optimizing the individual routines. In production code it's almost a sin to try and low-level optimize something that a profiler hasn't singled out and can't be refactored out. If you're getting paid to code something and you spend 5 hours on an optimization that gets factored out the next day you just wasted 5 hours of paid work. Sometimes I'll get 'the bug' (in my brain) and optimize something until it's ridiculous, but I always do so knowing that it's a pointless exercise, and I usually think up several ways to factor the code out even while I'm in the midst of my madness.
I posted something a while ago about an xor encryptor that I was playing with (it was making my hard disk stall and make a weird grinding noise). I optimized it by actually compiling bytecode for the encryption at runtime and then executing it, which is ridiculously fast, but the fact is that the choke-point in that app is the disk IO. I knew from the start that if I were to run the old (non-optimized) code while the app was async reading into the next buffer it would completely mask the encryption time, resulting in better performance without the tomfoolery. I just wanted to play with assembly for a while.
Posted by Khatharr on 30 December 2012 - 03:35 PM
I would totally play that game.