Spirrwell

Maybe a stupid question, but have you made sure your video drivers are up to date? It's been years since I used SDL, but IIRC it uses OpenGL on the backend, so if your GL drivers are still Microsoft bundled or otherwise non-accelerated, then OpenGL is going to be sloooow.

Actually, SDL 2.0 I believe is heavily attached to OpenGL, but with SDL 1.2 I think it's only true OpenGL code that benefits from hardware acceleration. I could be wrong though, I don't know if initializing the screen with SDL_OPENGL can be done without OpenGL specific code, but he could try adding that to the flags when calling SDL_SetVideoMode().

 

Don't know for sure though, just something to look into.

I think that the issue is simply that everything we have is built off of something and always will be. Every modern computer we have will always have the base machine code as Hodgman pointed out. I think the sense is that we have so much that is built off of an old foundation, and that we could make an entirely new foundation that would work better, but how could we get to that point without what we have now? Why not a computer that doesn't run on electricity whatsoever? With our current computer design, it would be impossible. Every device requires an energy source. A pencil is useless without the energy to use it. If you keep going back, every new thing was built off of a pre-existing concept. At one point there had to be absolutely nothing, so how do we go from nothing to an entire universe? How do we go from nothing to gravity, to chemicals? Chemicals that exist in our very computers today.

By all of this logic the universe has been stagnant for its entire existence. You could say that every game we have existed billions of years ago as just as scattered atoms. Either way, it came from something that was already in existence. I mean we could go back and start from scratch and redesign the way a computer works, but right now, this is what we have.

To be honest I started a project with C++ and SDL, was going perfectly until sprite rotation. SDL isnt friendly with sprites to be honest, and as it uses the CPU only and not the GPU it isnt very good to do the rotation on the fly, as it could cause major lag on many machines, If you want to create a quite simple basic game or program I would say go for SDL as it is nearly supported by everything, If you want something that uses the GPU and doesnt cause a huge amount of process to the CPU go for SFML. I converted all my SDL project to SFML in a very short time, and as I have worked with SDL before I feel that SFML is much easier and well...just easier to understand.

Canvas

Actually, you can mix OpenGL and SDL for hardware acceleration. (Someone correct me if I'm wrong). Basically you would use SDL_opengl.h for SDL's OpenGL functions.

Anyway, for simplicity and moderate portability, go SFML.

For massive portability and moderate difficulty, go SDL.

I haven't really used SFML, I just really found out about it yesterday in fact. It's really simple, or maybe I say that because I've been working with OpenGL and SDL for a while now. I personally strongly recommend SDL, as it's well matured and it has great portability. It's also a great starting point for understanding how some of the behind the scenes magic works. To me, SFML's weakness is its simplicity. That's just my personal opinion, I like being able to see what I'm working with and make it work for what I want it to.

I may not be the best guy to get an opinion from as I did just find out about SFML yesterday, but I did test it and got it to work no problem.

Not too bad, the animations are fine, not to say they couldn't be improved, but they don't look horrible, just simple.

When you "kick" the doors though, I can just hold q and move them anywhere I want. I can do this from like 20 or so ft away from the door.

There also seems to be a clipping issue with some of the walls. It looks like you might have two walls in the same place and depending on the way you view the wall it sort of leaks through.

I'm not sure if it was your intention, but the area where you walk by and hear the scream, you can keep walking by it and hear the scream. I would've personally just made it a trigger point and have it give a full scream once.

Also, as Krohm said there's the area where you crouch to walk, and fall down through the level. Aside from falling through the level, if I let go of crouch, the player stands up with his head through the ceiling.

All in all, not too bad for a start, but don't be cocky like you kind of were in your title by saying test your "epic" game. You might get a bad reaction with that attitude. Anyway, best of luck with Unity.

Alright, I'm going to ask to spare me the lecture of "Assembly will make very little difference speed-wise, Assembly is very difficult, and etc." Yes I know, but the point is I want to learn it and I already have a general understanding of how it's supposed work. I know that all CPUs have registers, and the 8086 CPU is what all modern CPUs are based from today. I know that these registers are faster than RAM, and standard registers are ax, bx, si, and etc. That is under 16 bit of course. I also understand the basic commands such as mov ax, 31. I'm also aware of interrupts, these can be used for handling peripherals, video, and such. My problem is simply this, finding a decent (free) book\tutorial that goes over all of this without being bound to Windows, Linux, DOS, or even the C language itself. I want it to be completely unbound from the operating system that it runs on, or rather, have no OS at all and simply boot it from a CD\floppy. My main goal is to make my own OS, but that will come later, right now I simply want to learn how do Assembly programming without being bound to an OS.

With that out of the way, I'd like to learn 32 bit and 64 bit Assembly. If anyone knows of any decent (free) books\tutorials that I could use, that'd be great. Any help is greatly appreciated.