 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi everyone,
Months ago I updated my NearInfinity demo, but never got around to
posting it. It can be found here:
http://www.caltel.com/~abenge/NearInfinity.zip
It should look like this:
http://www.caltel.com/~abenge/NIscreen.jpg
There is no goal to the game. You just fly around in a near-infinite
landscape. I would call it infinite, but even the best random number
generators don't go on forever. The landscape is not different every
time you start the program up. You can change the landscape's seed
within an .ini file. To make it a little more interesting, there are six
Easter eggs to find. They occur very rarely, and you get no reward for
finding them; they are simply there. Look at ee.png for spoilers :) Keys
are left, right, up and/or z. It has bouncy and smooth, but solid
collision-detection.
If you are running Windows, have DirextX 8.0 or above, and have some
free time, could you download it and tell me what you think? With the
default settings it should run at 60 FPS regardless on your monitor's
refresh rate. I kept the logic separate from the frame rate, so it
should work on your computer exactly as it does mine, as long as your
computer isn't really old. It will skip frames to compensate if your
computer is slow.
I would like some feedback on a few things. What is your operating
system? Does it work on Vista? What FPS are you getting? Do the default
settings of 1280x960 fullscreen mode give you ultra-smooth scrolling?
What about lower resolutions? You can change these and other settings
within the NI.ini text file. If you decide to run in windowed mode,
change dynamicFrameRate to method 2. You won't get the benefits of
VSYNC, and it really shows.
If for some reason I didn't upload the program with the default 1280x960
resolution and VSYNC settings, change the values found in NI.ini to these:
windowed=0
screenMode=2
dynamicFrameRate=3
Thanks in advance!
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> it should run at 60 FPS regardless on your monitor's refresh rate.
Actually, it should run at whatever your monitor's refresh rate is and
it should do it smoothly with VSYNC, without affecting the game logic.
I just caught a few bugs and uploaded a new version (with a green
landscape). For some reason, I had forgotten to free a texture, which
isn't good! There is now a delete for every new, and all textures and
entities are freed up like they should be.
There is an issue that's bugging me though. Can anyone tell me why I get
a warning when I try to delete an array of sprite objects like so:
delete [] tile;
The compiler does not complain when I delete them like this:
v=0;
for(y=0;y<8;y++){
for(x=0;x<8;x++){
delete tile[int(v)];
v++;
}
}
I don't know why. I initialized the array like this:
hgeSprite *tile[8*8]
and filled it like this:
v=0;
for(y=0;y<8;y++){
for(x=0;x<8;x++){
tile[int(v)]=new hgeSprite(tiles,x*132+1,y*132+1,128,128);
v++;
}
}
v is a float, by the way. I'm not calling int() for no reason. Should I
have structured my "new" differently?
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Dec 2008 22:38:26 +0100, stbenge
<THI### [at] hotmail com> wrote:
> There is an issue that's bugging me though. Can anyone tell me why I get
> a warning when I try to delete an array of sprite objects like so:
>
> delete [] tile;
Because it is the wrong thing to do?
> I initialized the array like this:
>
> hgeSprite *tile[8*8]
'tile' itself is not dynamically allocated. The elements contained in
'tile' however are pointers to dynamically allocated objects, and
therefore need to be deallocated individually.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson wrote:
> On Fri, 12 Dec 2008 22:38:26 stbenge wrote:
>> I initialized the array like this:
>>
>> hgeSprite *tile[8*8]
>
> 'tile' itself is not dynamically allocated. The elements contained in
> 'tile' however are pointers to dynamically allocated objects, and
> therefore need to be deallocated individually.
I see. The array itself was not dynamic, so there was no reason to
delete it. Despite my limited knowledge of the subject, I managed to do
the right thing by deleting them individually... They were deleted in
the same manner as they were created. There's more to this issue I need
to explore, and I'm not ashamed to admit it ;)
Who's going to trust my programs, now that my ignorance is known? I
could always provide the source...
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <THI### [at] hotmailcom> wrote:
> hgeSprite *tile[8*8]
> and filled it like this:
> v=0;
> for(y=0;y<8;y++){
> for(x=0;x<8;x++){
> tile[int(v)]=new hgeSprite(tiles,x*132+1,y*132+1,128,128);
> v++;
> }
> }
Does the HGE library force you to write code like that? If so, then it
really sucks.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> stbenge <THI### [at] hotmailcom> wrote:
>> hgeSprite *tile[8*8]
>
>> and filled it like this:
>
>> v=0;
>> for(y=0;y<8;y++){
>> for(x=0;x<8;x++){
>> tile[int(v)]=new hgeSprite(tiles,x*132+1,y*132+1,128,128);
>> v++;
>> }
>> }
>
> Does the HGE library force you to write code like that? If so, then it
> really sucks.
Don't use HGE to insult me... if that's what you are doing. I could have
written my loop a different way and used less code, but I feel
comfortable typing it out that way. I come from a
QBASIC/Euphoria/POV-Ray background, so I code the l_o_n_g way. Or do you
mean the way each sprite has to be made new? There might be better ways
to do it, for all I know.
I think a good programmer would be able make a large, clean program
using libraries that may have problems. I would like to be that
programmer, and I'm humble enough to admit that I'm not there. When it
comes down to it, all libraries and all languages are going to have
problems.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> There is no goal to the game. You just fly around in a near-infinite
> landscape.
That's very Zen. With the fading trails, that's sort of like one of those
rice-paper pads you write on with water.
> If you are running Windows, have DirextX 8.0 or above, and have some
> free time, could you download it and tell me what you think? With the
> default settings it should run at 60 FPS regardless on your monitor's
> refresh rate.
I think mine is saying 75FPS or so. I'm on Vista x64, and it runs flawlessly.
> I would like some feedback on a few things. What is your operating
> system? Does it work on Vista? What FPS are you getting? Do the default
> settings of 1280x960 fullscreen mode give you ultra-smooth scrolling?
Yes.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <^@hotmail.com> wrote:
> Warp wrote:
> > stbenge <THI### [at] hotmailcom> wrote:
> >> hgeSprite *tile[8*8]
> >
> >> and filled it like this:
> >
> >> v=0;
> >> for(y=0;y<8;y++){
> >> for(x=0;x<8;x++){
> >> tile[int(v)]=new hgeSprite(tiles,x*132+1,y*132+1,128,128);
> >> v++;
> >> }
> >> }
> >
> > Does the HGE library force you to write code like that? If so, then it
> > really sucks.
> Don't use HGE to insult me...
I was not insulting you. I was asking if that's the only way of using
HGE (because if it is, then HGE really sucks as a C++ library).
> I could have
> written my loop a different way and used less code, but I feel
> comfortable typing it out that way.
The problem is not the loop. The problem is the 'news' and 'deletes'.
While there are situations where their use is completely ok and in fact
the best thing to do, those situations are usually rare.
Usually the "correct" way of, for example, creating a certain amount
of objects like that is:
std::vector<hgeSprite> tile;
tile.reserve(8*8);
for(...)
for(...)
tile.push_back(hgeSprite(...));
(The word "correct" is deliberately in quotation marks because it's,
quite naturally, not *always* the best way to do it. However, in most
cases this - or something similar - is.)
However, depending on how hgeSprite has been designed, that might not
be possible. For example, if it doesn't have a properly working copy
constructor (or it has been disabled), then that method cannot be used.
If that's the case, then you indeed have to either allocate things with
'new', or use other dirty tricks to get it working. And it would also be
a sign of sloppy design in the HGE library.
The problem with using 'new' and 'delete' like that is that it's very
error-prone. C++ has its quirks with memory allocation, and you just have
to learn to live with them if you want to use it. Encapsulation is the key.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> stbenge <^@hotmail.com> wrote:
>> Don't use HGE to insult me...
>
> I was not insulting you. I was asking if that's the only way of using
> HGE (because if it is, then HGE really sucks as a C++ library).
Then please accept my apology :)
>> I could have
>> written my loop a different way and used less code, but I feel
>> comfortable typing it out that way.
>
> The problem is not the loop. The problem is the 'news' and 'deletes'.
> While there are situations where their use is completely ok and in fact
> the best thing to do, those situations are usually rare.
In the HGE tutorials, sprites are created in this manner, so I adapted
the method to work with arrays.
> Usually the "correct" way of, for example, creating a certain amount
> of objects like that is:
>
> std::vector<hgeSprite> tile;
>
> tile.reserve(8*8);
> for(...)
> for(...)
> tile.push_back(hgeSprite(...));
>
> (The word "correct" is deliberately in quotation marks because it's,
> quite naturally, not *always* the best way to do it. However, in most
> cases this - or something similar - is.)
>
> However, depending on how hgeSprite has been designed, that might not
> be possible. For example, if it doesn't have a properly working copy
> constructor (or it has been disabled), then that method cannot be used.
> If that's the case, then you indeed have to either allocate things with
> 'new', or use other dirty tricks to get it working. And it would also be
> a sign of sloppy design in the HGE library.
Thank you very much for this tip. I seem to remember that hgeSprite does
have a functioning copy constructor, so I should give the vector method
a go. Before I get there, I have to gain a better understanding of OOP
programming so I don't find myself hacking and experimenting with the
std::vector functions. Too much of my time is spent doing this, I'm
ashamed to admit :(
> The problem with using 'new' and 'delete' like that is that it's very
> error-prone. C++ has its quirks with memory allocation, and you just have
> to learn to live with them if you want to use it. Encapsulation is the key.
Another reason to get myself familiarized with all that C++ has to
offer. Thank you for your feedback!
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> stbenge wrote:
>> There is no goal to the game. You just fly around in a near-infinite
>> landscape.
>
> That's very Zen. With the fading trails, that's sort of like one of
> those rice-paper pads you write on with water.
I have no idea what you're talking about :)
>> If you are running Windows, have DirextX 8.0 or above, and have some
>> free time, could you download it and tell me what you think? With the
>> default settings it should run at 60 FPS regardless on your monitor's
>> refresh rate.
>
> I think mine is saying 75FPS or so. I'm on Vista x64, and it runs
> flawlessly.
>
>> I would like some feedback on a few things. What is your operating
>> system? Does it work on Vista? What FPS are you getting? Do the
>> default settings of 1280x960 fullscreen mode give you ultra-smooth
>> scrolling?
>
> Yes.
Thank you for trying it! You're input is valuable, considering my
girlfriend could not get it working on her Vista x64 laptop. It may be a
screen/video driver problem though. One of these days I'll have to make
a new MetroidVania :) (and finish it)
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
