blewisjrMember Since 11 Apr 2006
Offline Last Active Jan 24 2016 10:28 AM
I am 25 years old and involved in hobby software development while attending school for Information Systems Security.
- Group Members
- Active Posts 483
- Profile Views 9,686
- Submitted Links 0
- Member Title GDNet+
- Age 29 years old
- Birthday May 29, 1986
Has had an item featured
Posted by blewisjr on 14 January 2016 - 09:43 AM
Ok on topic I am designing a game. Well not exactly a game but a core framework to make endless game content and at the same time a game.
Think table top rpg gone digital.
So I am looking to put a tools together to create my dream game but obviously we need some restrictions.
1. The project will be 100% open source.
2. I would like to if possible to avoid c/c++ as I would like the project to be more approachable and the game will be turn based and 2d anyway so there is not much need for the "performance".
3. 2d for sure as this is a modular game thin NWN style. The game itself is a tool set the modules are actually the game. There will be pre made modules to enjoy but for a real custom experience custom art may be needed and 2d is more approachable for anyone to do.
4. As a advanced creator feature I would like custom rules etc to be create and this might involve some scripting so here I figure lua and or python would be perfect even if they need to be integrated in a c/c++ codebase.
So anyone more in the loop offer some suggestions. First there will be gui requirements for the tools and obviously I will need some sort of 2d api or engine probably api as this system is a unique case. If possible doing the whole thing in python would be awesome but from my experience python + graphics + gui has been a mess over the years.
So feel free to bombard me with opinions suggestions etal... Keep in mind despite this being in for beginners I was not sure where to put this I am not a new to making a game or programming. And yes I am go ogling like a mad man looking for options.
Posted by blewisjr on 14 July 2014 - 06:09 PM
I agree with most of the comments here. C/C++ are great to learn to use but they are fazing out in a lot of more common areas. They still have their place and will probably have their place for a very long time yet to come. Learning will make you a better programmer overall even in more modern languages. For games you really do not need C++ or C. There are lots of great technologies out there today that are beyond capable of keeping up. Heck even today much of the games you play are done with scripting languages and those languages hook into the C++ rendering engine on the backend.
The main reason I say C/C++ will be for around for a long time is mainly because of specific areas like kernel development as well as embedded micro controller development. Sure there are new languages coming out that are compiled to machine code like Google's Go. The big downfall of those types of languages is the lack of direct memory access through pointers and direct interfacing with assembly code. In the world of Kernels and embedded micro controller (think ARM Cortex M, PIC, AVR) you really need that otherwise you can't really do anything without extreme C interfacing hoops. Some of those chips are so tiny in memory you would be lucky to get a runtime driven language on them. These are extreme cases.
So in the end if you are learning your first language I would recommend it not be C++. I would rather see a new programmer on their first language use pure C, C#, Java, or Python. C is a very simple language to learn and will let you learn some really useful concepts this is still my all time favorite language. C#, Java, and Python are also relatively simple languages that rule out memory management and will allow you to focus on core algorithm concepts. Choose something you want to choose not what everyone forces you to choose and stick with it for a while before moving on. Every language you learn will teach you something new.
Posted by blewisjr on 14 July 2014 - 05:54 PM
Now that would be a sight to behold, my tutor scolded me for trying Lazarus instead of Delphi (I had a linux box so Delphi wasn't an option).
Your tutor might respect the fact that you are looking outside the box and towards solving issues of portability (a major topic within the game development industry).
Heh I had a teacher scold me for using GCC + Makefiles + Vim in my C++ class because it was all I had available at the time due to a computer explosion. Apparently Visual Studio is the only way to write C/C++ now a days in school.
Posted by blewisjr on 06 July 2014 - 07:35 AM
I could be off base here but are you sure the texture is even getting stored in the map? By the looks of your loadTexture function you are storing a local variable that will be destroyed when the function returns so when you try to access the data it is actually invalid memory because nothing is there. I could be wrong as I am not sure how SDL_CreateTextureFromSurface operates it might actually malloc memory not sure. It is just a thought to look into because a segfault is actually caused by accessing invalid (bad) memory. So the first place I would look is to make sure the texture is actually being stored properly.
Posted by blewisjr on 17 May 2014 - 10:15 AM
Posted by blewisjr on 15 November 2013 - 08:30 AM
Typically it is dangerous to use scanf on a fixed size array as from what I remember scanf does no bounds checking at all. It would be safer to either a use a char** or to use the version that does bounds checking which I think is sscanf(). I would do a search first as the name of the function may be wrong off the top of my head.
Posted by blewisjr on 15 November 2013 - 07:26 AM
How about instead you ask specific questions about issues you have and we try our best to better explain the concepts.
Posted by blewisjr on 25 October 2013 - 07:02 AM
The best book I could recommend by looking at all current books is The OpenGL Superbible 6th edition.
The authors decided to get rid of their wrapper library and instead show you raw OpenGL. They do have a set of headers to use that handles setting up GLUT and has a few mathematical things in there to make your life easier but this stuff is not hiding OpenGL in anyway.
The only downfall of this edition is the fact that it is OpenGL 4.3 so you need a video card capable of 4.3 or at least from what I can see 4.0 - 4.3. The author does claim most of the examples should work with 3.3 but there will be a bunch that do not.
This is a tutorial book if you combine this with the newest OpenGL red book (More of a reference then anything) you will be set and on your way.
Forgot to mention if you are looking to get into the basics without a book the best way to go is with this tutorial....
Posted by blewisjr on 17 October 2013 - 09:52 AM
I know many programming languages and it is really not the language that is difficult to learn this is often just various API, and Syntax. The best way others have mentioned is to learn by doing and researching as you get stuck. By doing this you learn various algorithms and data structures they carry over across programming languages and then it is really just about the syntax. This follows suit for all imperative languages and does not really break down till you try to learn a functional programming language where all the design patterns, algorithms, and data structures must be represented in a completely different way. So as long as you are sticking along the lines of C++, C, Java, C#, Python, etc... Learn by doing/researching eventually it will start to click and make sense. There is no way to just learn by just reading a book it really takes personal projects to get the total picture.
Posted by blewisjr on 09 October 2013 - 06:44 PM
Seriously listen to these guys and do not mess around with 16 bit asm + dos. If you want to start simple pick up a AVR 8bit chip. There is also PIC but pic uses a banked/paged memory system on a lot of their chips which makes things dumb. With AVR 8 bit you have about 130 instructions or so and properly aligned memory that is not split off into chunks. After you get bored with that which you probably won't go an move to ARM.
I started with PIC but after getting tired of all the bank switch and crap I moved to AVR and it is much nicer to work with at the asm level. Eventually I plan to move to ARM and mess about there at some point maybe.
I use bare avr chips not the arduino platform because arduino makes it a nasty hack to do any asm with it.
The only issue with working with the micro controllers is to really do anything interesting you are going to have to learn some electronics. I found this the most difficult part is the actual electronics not writing of the firmware which even in asm is relatively easy.
Right now I am working on a sound activated trigger switch using a AVR and a Microphone. Still trying to understand the electronics behind it already understand the firmware part.
Posted by blewisjr on 18 June 2013 - 12:57 PM
I am looking for some advice from any embedded software engineers and/or mainframe programmers out there. Where should someone looking to develop real time systems really begin? I am turning 20 in August, figured I would really try and buckle down on something and this is it. I haven't gone to university at all because I still need to get my GED so until then specialized schooling is not an option. Since leaving high school I managed to pick up Perl, C, Lua, x86 (to some extent) and 6502 assembly but I'm not exactly interested in programming for video games anymore despite finding some small successes there. I find engine development and optimization on microprocessors to be much more fulfilling despite the mundane aspects of such tasks. The real question is, is there anything else I sould be doing to try and accomplish this? Are there any excersises I should be trying or particular languages (like learning to write ARM asembly?) I should highlight? Any other tips would be greatly appreciated, thanks!
Ah this really depends on where you want to go with embedded software. Do you want to develop for an embedded device like a phone or are you looking to develop your own systems from the ground up. When I got involved in embedded as a hobby I wanted to go ground up.
Some people suggested Arduino and in all honesty it is a great platform but it is exactly that a bloated platform that will hinder your growth at some point. It is great for just getting started but you will want to move away from it quickly.
In the current perspective assembler is not really needed C can do just fine but I prefer the assembler for 8 bit chips because there are quite a few gotchas you that will bite you at some point with C. For instance real time systems including video and time keeping are not really something C does well in the embedded process. One such example was my alarm clock built with a 8 bit PIC micro controller. I started with C and all was good but the C actually caused some issues when dealing with timing. C is not a 1 to 1 instruction setup and the actual generated assembler was throwing of my clock by quite a bit and with all the optimization I could possibly do it just was not accurate enough so I converted the important code to assembler to solve the timing issues.
As for Assembler every chip has it's own Assembler suite and non of them are identical. PIC is different then AVR which is different then ARM. From a assembly perspective PIC is much easier to learn and the chips are quite a bit cheaper as well.
This is of course assuming you want the ground up approach that I took. In which case you need to learn some electronics theory for circuit design, as well as programming a particular micro controller.
My recommendation would be AVR or PIC 8 bit chips to start. My opinion stands strong that Arduino is a waste of time if you really want to learn it is just wrappers on top of wrappers and bloat. The only advantage is rapid prototyping. I disliked it so much I pulled the chip and erased it and through the board away and kept the chip for a different project. But to each his own it might be what you want so don't rule it out because I said it is bad.
Embedded is a deep hole to swim in if you have no clue the direction you want to go but there are tons of people that can help you out. My suggestion is to get an account over at www.eevblog.com watch some of Dave's videos on youtube. Ask every question you can even if it is stupid you will get tons of valuable information. Just don't ask about ASM vs C because it is about as heated at C++ vs <insert language here> gets on these forums. Actually it is even worse just pick one and go for it don't worry about what others say.
Posted by blewisjr on 11 March 2013 - 03:26 AM
Any Language can work it does not matter what so ever as long as you have access to graphics libraries. SDL is probably not the best choice for 2.5D. If you want to use C++ you would have much better luck doing 2.5D with SFML because it is a full hardware accelerated library with easier bindings into OpenGL if you find you need to use it later on.
Posted by blewisjr on 10 March 2013 - 04:41 AM
Posted by blewisjr on 07 March 2013 - 02:44 PM
Generally ignore the concept of observers.
The general gist is you have...
A model: which is a representation of the data
A Controller: Tasked with manipulating the data and applying logic to the data
A View: Tasked with displaying the data.
So you may have a model called ProductList. It stores a bunch of products.
The controller would contain methods to say add a product or remove a product and a method render the appropriate view
The view would display the data and possibly allow interaction with the controller.
Essentially you are creating a chain of command. You see the data with the view and you use the view to tell the controller what you want. The controller is the middle man between the view and the model to ensure everything done to the model is done properly. The goal is to create a layer of separation between your data, data logic, and visual data representation.
Bringing Observers into it just complicates the understanding and I feel it is not really necessary.
Posted by blewisjr on 07 March 2013 - 02:34 PM
No there will be no shader like manipulation languages for audio. All the audio calculations will probably have to be run through the CPU. As far as manipulating the audio he will probably need to write algorithms to manipulate the raw audio bits that are stored in the buffer. This is rather low level programming but there may be api's out there that glue well with OpenAL to get the effect you want I am not sure. The best thing is to take a step back and do some research on audio manipulation. Some tools like audacity allow you to apply filters to the audio to get different effect and it may be worth looking into the source code of the project to see how they implement the filters. From a general perspective audio is nothing more then voltages converted to audible tone frequencies so without a doubt he is going to have to get good experience with the lower level details of development because at some point he will have to bit twiddle.