Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Scienthsine

Member Since 25 Sep 2008
Offline Last Active Sep 25 2012 09:16 AM

Posts I've Made

In Topic: Preferred development OS (Desktop/Laptop).

25 September 2012 - 09:16 AM

Within the last year I've started developing using arch linux with dwm and vim. Mostly C and Go atm. I find that using the command line tools and vim is what I like. I don't mess with icons, I don't mess with file managers, I don't mess with menus. I can actually do everything from the keyboard without ever using the mouse. Infact, other than my browser, I can do all my coding over a simple ssh login, or without starting xwindows at all. Even while in xwindows, dwm has no need for a mouse, and I'm using vimium for chromium to reduce my need of a mouse there. Dwm is a tiling window manager, which is very helpful when using documentation or reference material.

There's much more to add, but I really enjoy my development environment. Everything at your fingertips.

In Topic: How to get the number of solid tiles between two points?

23 September 2012 - 11:14 AM

The picture actually looks like it's using Bresenham's algorithm. Notice how it favors one axis (Y) over the other (X)? Even though the actual line covers some tiles by almost half, they aren't in red, while others are barely covered and are in red. It's iterating over Y with error accumulation in X.u

Basically forget the pixel level of it all. Your creating a line between two tiles. Using Bresenhams algorithm over the tiles is the same as using it over pixels.

Now, as others have said, if your really just wanting 'the number of solid tiles between two points' and your counting the tiles in red in the photo, then it is just the greater of the absolute of the difference in Y or X. (As defined by the outer loop in the algorithm.)

In Topic: Yet another OOP question.

19 September 2011 - 06:56 PM

Well my 'wrapper' will have a much higher level of functionality. ie: CreateSprite, CreateTileMap, etc...

Not quite sure what your getting at. Do you not believe in 'wrappers'? You seem to imply that all software is just a wrapper on top of the machine level assembly data.

I'm quite sure most people 'wrap' the gl commands in some sort of higher level draw commands. My question is: In those higher level functions, do most people call the gl* commands in their native C style API, or do they wrap those commands and GLuint datas into C++ classes? Or rather than 'most people' do 'you' (other gamedevs)?

In Topic: [SOLVED] glBindAttribLocation and NVidia

01 December 2009 - 01:25 PM

Ohhhhhhhh ok!

I think this tutorial has the wrong idea then: http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php

I felt that they were saying that those indices are reserved for built-ins only.

In Topic: Getting started with GL3.0

26 September 2008 - 04:54 AM

Quote:
Original post by apatriarca
Quote:
Original post by Peti29
I find it totally crazy to remove matrix operations. At least they should have replaced them with functions that for example receive a transformation matrix and a rotation and return a matrix that represents the rotation applied to the src matrix. Dont tell me this would complicate drivers!
Removing matrix operations is a massive feature-loss in my eye. Ofc sooner or later you gonna have to manage your matrices but those matrix operations were very handy for beginners IMO.

Those features are probably only useful for beginners. I personally think it's easier to work directly with matrices than track the current state of the matrix stack and there are a lot of situations where you can't use the matrix operations OpenGL gives (for example if you use quaternions for animation). You can't really be a graphic programmer if you can't work with matrices with easy, so you have to learn to do it sooner of later.

Edit: OpenGL 3 continue to support those features. You can still use the fixed pipeline if you want to. Those features will be removed in future versions of OpenGL, not in the current one.


Aye, but using depreciated features is not exactly ideal. I think the matrix stuff should be moved to glut or glu or whatever. I'm actually doing without them at the moment since I'm doing 2d, and it's pretty simple to do all the translation/rotation/scaling and such without the matricies. Gamedev has a few articles about the subject though. http://www.gamedev.net/reference/articles/article877.asp

Once again... my argument isn't that they're being removed, so much as we need new tutorials. With the information available, I don't think someone can learn OpenGL 3.0 proper code from scratch very easily... and it may be even harder for a beginner who started in opengl 1.x or 2.x to try to make the switch.

PARTNERS