- Oldbie: Oldbie
- Active Posts:
- 348 (0.09 per day)
- Most Active In:
- General Sonic Discussion (38 posts)
- 11-January 03
- Profile Views:
- Last Active:
- Today, 01:57 AM
- 25 years old
- September 12, 1987
- National Flag:
- Wiki edits:
Posts I've Made
24 September 2012 - 07:41 PMNo prob.
I don't think Visual Studio was necessarily "fixing" anything. The exact behavior when writing out of bounds of an array is undefined. In practice, it depends on the layout of memory. I'd guess that Microsoft's compiler/runtime laid out memory in such a way that there was valid data immediately before or after the array; perhaps some other variable or what have you. So writing out of bounds would have corrupted some random program data elsewhere.
You only get an error if you write/dereference outside of the program's allocated area of memory, which isn't always true when going out of array bounds.
24 September 2012 - 03:03 PMThe new line still isn't valid because the * should be before the type name, not after
Nope. In C++, for a dynamically allocated array of pointers, the asterisk goes after.
It's in the format of
a = new type[elements];
In this particular case, the type happens to be 'pointer to state' which would be written as 'state *'. Therefore, asterisk goes after. It only goes before if you're dereferencing a pointer, declaring a static array, or declaring a single pointer variable, I.e.
mytype *p1, *p2, *p3;
24 September 2012 - 01:05 PMTaking a glance at your code, however:
M = new state*[size];This shouldn't have compiled because the * is just there where it shouldn't be. Did you mean
M = new state[size];?
No, it looks like M is a two-dimensional array. That line is perfectly valid code because it's allocating an array of pointers to 'state', then in the next few lines it's iterating through each pointer and allocating an array of 'state' objects, thus forming the 2D array.
But yeah, the error means that you're writing to memory you shouldn't be writing to, or perhaps dereferencing an invalid pointer. Another way to debug this (besides using a debugger) is to insert print statements to print your indexes. Make sure everything is in bounds.
18 August 2012 - 09:13 PMWith Sonic fangames in general, they're either ROM hacks or use tools like Multimedia Fusion, Game Maker, SonicGDK, or some other existing engine. People coding an engine from scratch is actually fairly rare around here, but obviously it can be done.
From the sounds of it, you're using C/C++. In such a case, SFML 2.0 is a pretty good library. For a 2D game, it has most of everything you need; hardware-accelerated graphics, input, sound, networking. Another decent one (if you don't mind pure C-style) is Allegro 5 (docs here), which is about as complete as SFML. It just has a different API style.
If you're just starting out with game development, I would recommend making simple games first, like Pong, Breakout, Pacman, Mario, etc. You don't want to overwhelm yourself with new concepts all at once, so you have to build from simpler things. But once you do get to things like, say, Sonic games, the Sonic Physics Guide can be very helpful in implementing classic Sonic physics. But like I said, don't try to do Sonic games as your very first game programming project; there's a lot of lower-level concepts and things going on that you need to grasp first.
09 August 2012 - 02:53 AMVirtual Audio Cable may be what you're looking for. Not free, though. If you choose the "self-support" option, it's around $25 (or $0 if you're so inclined :P). There's also a trial version so you can see if it works for you.
Delta hasn't added any friends yet.