Jump to content

  • Log In with Google      Sign In   
  • Create Account

blueshogun96

Member Since 09 Jun 2005
Offline Last Active Today, 09:33 PM

#5042544 Chess and OpenGL

Posted by blueshogun96 on 12 March 2013 - 07:23 PM

Question, how new are you to OpenGL?  I have the feeling you're getting a bit ahead of yourself; trying to take on a project that may be a bit too large for your current skill level.  Sorry if I'm wrong, but that's sorta the vibe I'm getting.

 

If you already have your chess pieces exported from 3dsmax, what you need to do is export them to a 3d file format that's easy to read/parse.  3DS, MD2, LWO, OBJ, etc. are good formats to start off with.  If you have never written a 3D mesh file loader, then you need to start there.  After you've chosen your file format, you need to read in the vertex data and then you translate the meshes to their respective positions.  If you know the size of your chess board, then putting the chess peices in their respective squares just requires you to translate them by multiplying the square size by the number of squares from the origin.

 

Back to the 3D loader part, if you cannot write your own 3D loader, then give Assimp a try: http://assimp.sourceforge.net/

 

If you want some sample code that specifically deals with a chess game with OpenGL, check out the SGI page here and click the chess example: http://www.sgi.com/products/software/opengl/examples/more_samples/

 

There's another one out there, but I can't remember where it is.  I'll have to find it again because it actually plays through an entire game of chess while moving the pieces on it's own.

 

Shogun.




#5042536 Change addressing mode with ID3DXSprite

Posted by blueshogun96 on 12 March 2013 - 06:56 PM

I prefer to avoid using ID3DXSprite to avoid confusion and portability (I found out the hard way that the 360 XDK didn't support it).  What I ended up doing is writing my own 2D sprite rendering code with an Orthographic projection and HLSL shaders.  Then you won't have to worry about state blocks, implement your own batching code, renderstates are a bit more straight forward, etc.

 

I can share it if you'd like.  Right now, I'm on my Macbook again, so I have no Direct3D code on it's HDD.

 

Shogun.




#5039382 PSP games in C++

Posted by blueshogun96 on 05 March 2013 - 01:25 AM

Can I ask you a question?  Is there a specific reason you choose PSP over PS Vita?  Or maybe it's because you already have a PSP.  I also assume that you don't plan on selling anything you create for PSP.  If you do, you're better off targeting PS Vita.

 

Anyway, I agree with Frob here.  I started to touch PSP homebrew before, but didn't get too far into it.  

 

Keep in mind, that when programming for consoles (especially handhelds), you should familiarize yourself with the hardware as much as possible.  Unlike PC, Xbox1, as well as the upcoming 720 and the PS4, they generally don't have x86 processors.  You have to know how to optimize your code to utilize the hardware's chipsets, and let me tell you, it's nothing like dealing with PC!  Example, PSP has what's called a VPFU, which is a vector unit with a very specific instruction set.  Afaik, you can't program for that directly with C++; you have to use it's customized assembly language.  If you've never used assembly language for any specific processor, be warned, it's not easy.  And if you're going to use C++, I recommend keeping it simple.  Going OOP crazy isn't very optimal on such hardware.  I'd rather just use pure C.

 

Another thing you need to remember is that unlike PCs, developing for consoles (once again, especially handhelds), your memory and other system resources are VERY limited!  The PSP is a prime example.  The PSP only has 32Mb of system memory, and 2Mb of video memory.  That's not much, so your games have to be memory efficient; tight down to the very last byte!  So you'll find yourself optimizing your resources to fit within those memory constraints.   Don't expect things like texture and audio formats to be the same or even similar to PC either.  A few 32-bit textures will chew up that video memory in an instant.

 

I'm all for you pursuing this if it's what you really want, just don't expect it to be as simple as programming for PC.  There's a site I want to link you to, but I don't know if it's against the rules or not, so I won't risk getting into trouble.

 

Shogun.




#5038663 OpenGl or Directx learning books..

Posted by blueshogun96 on 02 March 2013 - 11:59 PM

Whether you're using AMD/ATI or not, those samples should work (the Direct3D ones at least) and aren't always vendor specific.

 

Anyway, you can download the DirectX SDK here: http://www.microsoft.com/en-us/download/details.aspx?id=6812




#5038657 Directx8 error LNK2019: unresolved external symbol PLEASE HELP!

Posted by blueshogun96 on 02 March 2013 - 11:47 PM

Question, are you using the latest DirectX SDK?  Or are you using the actual DirectX 8 SDK?  There's a chance you might be getting the DX9 version of those interfaces which is likely changed since DX8.  I've had this problem before, and it can get annoying sometimes.  Be sure that you're only linking against the DX8 versions.

 

If I were you, I'd be looking at the MSDN documentation of those interfaces you are having problems with.  I understand that you are new to all of this, but eventually you will need to learn to look to the API documentation when things of this nature arrive.  So, from here, I recommend at least opening up the DirectX 8 SDK help file along side of the DirectX 9 SDK help file to see what the COM interface differences are so you can pinpoint your problem.  If you don't understand what the different parameters are for, then let us know.  Since I have both SDKs installed on my Windows machine, I'd be glad to do a little searching myself for you, but I'm on my Mac right now, which doesn't use DirectX.

 

Shogun




#5038634 OpenGl or Directx learning books..

Posted by blueshogun96 on 02 March 2013 - 10:05 PM

Here's a few I recommend:

 

http://www.codesampler.com/dx9src.htm

http://www.dhpoware.com/demos/index.html

 

I also recommend the GPU Gems books series as well as downloading the NVIDIA SDKs:

 

https://developer.nvidia.com/gpu-gems

https://developer.nvidia.com/nvidia-graphics-sdk-11

 

NVIDIA has alot of great stuff and really useful code samples that I've been fascinated by for years!  Most definitely do not pass these up. smile.png

 

Shogun




#5038632 PS3 games in C++..

Posted by blueshogun96 on 02 March 2013 - 09:52 PM

Well said Daaark.  I've been around the homebrew scene since 2004-ish.  Tbh, I was one of those people you described.  As I grew out of the whole homebrew scene, I started maturing and getting more focused and more serious about what I was doing instead of dicking around.

 

I won't say that there's no talent or good content in the homebrew scene, but it's mostly full of hackers and stuff.  While this is to be expected, I find majority of "homebrew" console games to be quite unprofessional and usually has a very amateur feel to it which makes it harder to take seriously.  What I'm about to say next may offend some people (and I could be wrong, so feel free to correct me), and if I do, I apologize and hope that you'll forgive me, but what's worse about the homebrew scene is the type of users they tend to attract.  I'm not saying they're all like this, but there are lots of pirates who will pirate your game, leak it to their buddies and torrent the living heck out of it like there's no tomorrow.  Of course pirates are everywhere, but I noticed that they tend to gravitate to that scene.  Well, after that silly rant, I had to stop and say to myself "that's right sherlock, pirates need hacked consoles to pirate their shiznit!"

 

I thought it was the most awesome thing ever (being able to run open source PC games on an Xbox1 HDD), but given my reasons above that's why I backed away from it.This is just my opinion though.  These days I strive to keep my work a step above that to say the least by avoiding the homebrew style and when necessary, avoiding the "indie" look.

 

Shogun.




#5037706 D3DXFont Z-Positioning

Posted by blueshogun96 on 28 February 2013 - 01:43 PM

I personally prefer to avoid ID3DXFont when possible.  Instead, I wrote my own texture based font class and was ultimately happier using it.  This way, I could have more control over my code and even z-ordering if necessary.

 

This link does a decent job of explaining how it's done: http://cboard.cprogramming.com/game-programming/70990-font-rendering-direct3d.html

 

If you want, I can share mine.  ^^

 

Shogun.




#5037502 C++/DirectX Tutorials?

Posted by blueshogun96 on 28 February 2013 - 02:22 AM

Hi, 

 

There's tons of tutorials and other resources to get you started.  Unfortunately, I haven't had the opportunity to write games for Windows 8 yet (need a new PC/Laptop), so I can only give you links to things of that nature.

 

Before you get started, you'll need to download a compiler.  For Windows, I recommend Visual C++ Express.  Click here: http://www.microsoft.com/visualstudio/eng#downloads

 

After that, you need to download the DirectX SDK.  This has all the tools, libraries and other things used to build DirectX games. http://www.microsoft.com/en-us/download/details.aspx?id=6812

 

Mastering C++ and DirectX usually takes lots of practice and persistence to gain experience.  So always practice and try to learn as much as you can, but don't overwhelm yourself.  It's important to learn at a pace that is best for you!

 

C++ primer for games: http://www.cprogramming.com/game-programming.html

DirectX 9 Tutorials: http://www.codesampler.com/dx9src.htm

DirectX 11 Tutorials: http://www.rastertek.com/tutdx11.html

Intro to DirectX for Metro Apps: http://channel9.msdn.com/Events/Build/BUILD2011/PLAT-766T

 

Hopefully these links will be of use for you!

 

Shogun




#5037132 Loading TGA - problems

Posted by blueshogun96 on 27 February 2013 - 07:22 AM

If you go blindly copying and pasting code from random sources, then they are not guaranteed to work.  I highly recommend understanding how the code works before actually throwing it in your project.  It will save you much hassle.  You sound like you are very new to OpenGL (please correct me if I'm wrong).  If that's true, I strongly believe you are better off writing your own code to get a good understanding of what is going on.  You cannot rely on someone else's code all the time, and it's best to learn to walk on your own two feet at some point, even if you have to crawl first.

 

Now, I'm assuming that you're using Microsoft Visual Studio C++ as your compiler/IDE, right?  My recommendation to you is to insert a breakpoint before your call to m_Model->Initialize().  Start debugging, then when your breakpoint is hit, step into that function and follow it until you find out what's causing it to fail.  If you don't know how to use breakpoints, or don't know what a breakpoint is, read this: http://msdn.microsoft.com/en-us/library/ktf38f66(v=vs.71).aspx

 

Lastly, I don't mean to sound like a douchebag, but did you even read the code you've copied and pasted?  I took a look at the tutorial page you linked to and I'm 99.9% sure that the problem is with your .tga file isn't found.  If you're launching your .exe from Visual Studio, then you might need to change your working directory in the project settings.  And changing the directory with SetCurrentDirectory doesn't look necessary to me.  Reading from the wrong directory is likely your problem.

 

This is my advice to you.  Maybe I'm wrong, but you seem rather new to C++, Win32 programming and Visual Studio .net.  If this is true, please tell us so we can point you in the right direction so you can learn more!

 

Shogun




#5037075 Universal OpenGL Version

Posted by blueshogun96 on 27 February 2013 - 04:05 AM

I know this would be more work, but in my experience, I found it easier to allow the user to choose which OpenGL version the want/need.  Example, for Windows, I like to create a basic API for gfx and write seperate .dll files for the various differing APIs and load those via ::LoadLibrary(), similar to what Unreal Tournament does.  It helps when compatibility reasons occur, but at the same time you can't limit yourself for the sake of a very small percentage of users.  If id Software did that, then Doom3 wouldn't have done so well (IMO).

 

It's been asked before, but what exactly is your target audience?  What type of game(s) do you have in mind?  If you're doing a 2D game or a really basic 3D game without much gfx complexity, then it won't really matter so much.  If you're doing a 2D game with some advanced effects, then I'd recommend doing no less than 2.x.  If you're doing a hardcore 3D game, then OpenGL 3 or higher is like an absolute must.

 

I'm working on a 2D OpenGL game for MacOSX.  Since most Intel based Macs and Macbook Pros support OpenGL 3.2, using it isn't going to effect compatibility very much, is it?  Windows and Linux users, on the other hand, have a greater variety of hardware and drivers.  So on the latter two OSes, compatibility is more of an issue.  You also have to keep in mind that as hardware evolves, the API also evolves to fit the needs of the hardware, not vice versa.  Some vendors have to go through hoops to maintain compatibility with OpenGL 1.1!  2.x is not so bad, but OpenGL was in dire need of a rewrite (and still is) due to it's limitations on current hardware.

 

Overall, you need to do what's best for your game!  Not what's best for the stubborn user that refuses to get with the times.  Sorry to sound like a douchebag, but there comes a time where the line must be drawn and the cut off point has to be enforced so we can move on without looking back.  Example: Unless you're catering to a very specific group with this interest, would you make your game compatible for those 'ol DOS users?  Or would you use DirectX 3.0 for those retro PC gamers?  As much as I enjoyed the days of DOS, and even more so, how much I would absolutely LOVE to go back to 1997 and write PC games with DirectX 3.0, I can't let such things hinder my game's progression and potential.  If you use the latest version of OpenGL, I doubt you'd get many people complaining about compatibility, unless it's a casual game that lots of everyday people will be using.  Then you'd get some 30+ year old soccer mom wondering why it's not working on her Netbook PC or low end laptop.

 

Sorry for ranting, that's just my view. ^^

 

Shogun.




#5035315 How do I determine the maximum VBO size?

Posted by blueshogun96 on 22 February 2013 - 01:48 AM

I googled this and didn't find any documentation regarding a limit on VBO size.  I also read that if there's not enough memory for a VBO, then it will be placed in system memory.  

 

Also, I wanted to ask you this, are those 400,000,000+ primitives always within your viewing frustum?  I really hope you're culling everything you're camera isn't facing! wink.png




#5035254 OpenGLES Game engine

Posted by blueshogun96 on 21 February 2013 - 08:52 PM

Sure anytime!

 

There's some books on OpenGL ES 1.1 and 2.0, but I haven't read any of them and there's lots of 'em that got some mediocre reviews.  I'll link to the two top rated ones on Amazon.com

 

http://www.amazon.com/Learning-OpenGL-iOS-Hands--Programming/dp/0321741838/ref=sr_1_2?s=books&ie=UTF8&qid=1361501222&sr=1-2&keywords=OpenGL+ES

http://www.amazon.com/Pro-OpenGL-Android-Professional-Apress/dp/1430240024/ref=sr_1_3?s=books&ie=UTF8&qid=1361501222&sr=1-3&keywords=OpenGL+ES

 

Be warned that the 2nd one (which is for android) uses OpenGL ES 1.x.  It's kinda old, but the transition to 2.0 isn't too tough.

 

Just remember, to take your time and don't rush.  Try not to sweat the small stuff and learn at a pace that works best for you!

 

Shogun.




#5033660 Screenshot to texture

Posted by blueshogun96 on 18 February 2013 - 01:40 AM

I think it would be better to create a dynamic texture, lock them both and copy the data manually.

 

IIRC, I tried doing something like this before, but ended up using D3DX's render to texture method instead (but that was for C++).

 

If you haven't already, you should look at the MSDN documentation for StretchRect[angle] and GetRenderTargetData.  I took a look myself but couldn't find a working solution either. unsure.png 

 

Shogun.




#5033630 Problem rendering Quake 3 BSP files

Posted by blueshogun96 on 17 February 2013 - 11:18 PM

Instead of using triangle fans, you're better off using indexed triangles.  Not every Quake3 map will render properly if you use triangle fans.  I made the same mistake for ages and that's how I fixed my bogus vertex data problem.  My renderer is Direct3D based so it might not help much.  If you want it anyway, I can upload it and hopefully it will help.

 

Shogun.






PARTNERS