Tests of SVN snapshots

For discussion of the code running behind the game

Moderator: Staff

User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Tests of SVN snapshots

Postby Bertram » Fri Feb 26, 2010 8:23 pm

Hi everyone,

I've been following this fantastic project for a while and with my few time left, I thought I could help by testing the latest SVN...

So far, I noticed two things in SVN revision #1747 with Code::Blocks Win Debug32 build:

- First, the winDbg32 binary seems to be heavy: 131 Mb. It may be me, but if it can help...
- Secondly, when entering the barracks, I get stuck at the entrance. My character can change direction, but won't move.

I hope this will help. I can't wait for the next release.

Best regards.
Last edited by Bertram on Thu Mar 18, 2010 12:22 pm, edited 3 times in total.
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Test of SVN #1747 with Code::Blocks Win Debug32 build

Postby rujasu » Fri Feb 26, 2010 8:46 pm

Bertram wrote:Hi everyone,

I've been following this fantastic project for a while and with my few time left, I thought I could help by testing the latest SVN...

So far, I noticed two things:

- First, the winDbg32 binary seems to be heavy: 131 Mb. It may be me, but if it can help...
- Secondly, when entering the barracks, I get stuck at the entrance. My character can change direction, but won't move.

I hope this will help. I can't wait for the next release.

Best regards.


Hi Bertram, thanks for signing up and giving us the feedback!

The binary might be a bit big. I only set up the Code::Blocks project last week, so I'm sure there's room for improvement. You could try building the release version as that may have a smaller size. Glad to head it's building properly though.

Yeah, there's a bug in the barracks entrance. I should have it fixed by tonight, so keep an eye out for the commit.

Any testing of the SVN is always appreciated. We'll be putting out a new release very soon. :)
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Test of SVN #1747 with Code::Blocks Win Debug32 build

Postby rujasu » Sat Feb 27, 2010 5:45 am

Barracks doorway bug is fixed in SVN revision 1749.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN #1747 with Code::Blocks Win Debug32 build

Postby Bertram » Sat Feb 27, 2010 2:45 pm

Glad to see that. ;)

I'll have a look at the barracks asap :approve:

While I'm on it, and if I humbly may:
I was intrigued by quite a visible change between the svn and the last demo and I just wanted to ask you
what was the reason of such a change, maybe you can tell me:
The character zooming has increased between the two demos and with the current player and tilesets graphics provided, the former demo looked more 'clean' (by clean, read less pixelized) than the current one.
Maybe it's the wanted spirit, but the character's portrait, and dialogue widgets are contrasting IMHO.

Another low point is that the view range while running around (because of the current zoom) seems a bit narrow to me.

I wondered then if you wanted to adapt the playersets, and tilesets, or were forced to use the current view for some other reasons. I obviously preferred the former zoom that fits more the gui polishing you made so far, and brought a clean game experience. And that's why I started to follow your project (btw). ;)

Again, please don't take anything personally as it's already a great piece of work, which will bring a nice short story to the community.

Thanks again and best regards.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Test of SVN #1747 with Code::Blocks Win Debug32 build

Postby Roots » Sat Feb 27, 2010 6:23 pm

The zoom was changed because a few people had constantly griped about how far away the sprites were and how "detached" they felt from the game as a result. We played around with a few different zoom levels in the early development phase of this release. We're releasing at this zoom to gauge the reaction and to see what zoom people like best. I used to be against the closer zoom, then I thought it wasn't so bad, and now I'm kind of torn between the two. I think that both zoom levels have their advantages and disadvantages. At some point I'm sure we'll have a formal discussion about the zoom on the forums and decide where to go from there.

So the current zoom isn't necessarily going to be the zoom that we stick with. Its just an experiment or a test if you will to see if it works better.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN #1747 with Code::Blocks Win Debug32 build

Postby Bertram » Sun Feb 28, 2010 3:47 pm

Hi Roots,

Thanks for the reply.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN with Code::Blocks Win Debug32 build

Postby Bertram » Mon Mar 01, 2010 1:10 pm

Hi again,

I tested the latest SVN snapshot (rev 1760) lately, and here are little things I catched on the way, again IMHO:

- When changing maps, you often appear at the same spot, whatever the map you came from.
Plus, you often appear quite in the middle of the map, rather than from the corner you came.
Try moving from the Desert outskirts to the training hall, of from the training hall to the western cave.

- The presence of a saved game should be indicated in the load menu, at least giving the save date and the current map, IMHO. (A screenshot or the image next to the "File #n" corresponding to the map (like the one for the desert outskirts) could be a plus.

- I also experienced a crash when walking from the training hall to the desert outskirts once. And I couldn't reproduce it under gdb, sorry :/ Anyone else did have the crash?

- Esc in the main menu should show a pop-up asking if the user really want to quit, or at least it should quit when you're in the middle of a sub-menu, but rather close it.
-> Try open the options menu, and press esc as many would do to close it.

- The map switching fade out seems a bit slow to me, but the fade in is fine.

Thanks for reading and best regards.
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Test of SVN with Code::Blocks Win Debug32 build

Postby rujasu » Mon Mar 01, 2010 2:52 pm

Bertram wrote:Hi again,

I tested the latest SVN snapshot (rev 1760) lately, and here are little things I catched on the way, again IMHO:

- When changing maps, you often appear at the same spot, whatever the map you came from.
Plus, you often appear quite in the middle of the map, rather than from the corner you came.
Try moving from the Desert outskirts to the training hall, of from the training hall to the western cave.

- The presence of a saved game should be indicated in the load menu, at least giving the save date and the current map, IMHO. (A screenshot or the image next to the "File #n" corresponding to the map (like the one for the desert outskirts) could be a plus.


These are both current limitations of the engine, we plan to add more polish in these areas at some point.

- I also experienced a crash when walking from the training hall to the desert outskirts once. And I couldn't reproduce it under gdb, sorry :/ Anyone else did have the crash?


We're working on this issue.

- Esc in the main menu should show a pop-up asking if the user really want to quit, or at least it should quit when you're in the middle of a sub-menu, but rather close it.
-> Try open the options menu, and press esc as many would do to close it.


I don't know that this will be fixed any time soon. I definitely see the problem, but there are bigger issues we need to concentrate on for the time being. Eventually, though, we may come up with a more elegant way to exit.

- The map switching fade out seems a bit slow to me, but the fade in is fine.


I've found that performance in general seems to be a problem with the Win32 build. We'll definitely try to improve this.

Thanks for all of the feedback.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Thu Mar 04, 2010 6:21 pm

Hi again!

I gave a try to the SVN rev 1766 (wanted to fight a bit ;) ).

This time, I tried to compile it under Linux Debian Unstable.

Compiles fine, but the binary doesn't seem to do anything.

I ran it under gdb and the bt gives this:
(gdb) bt
#0 0xb7fe1430 in __kernel_vsyscall ()
#1 0xb7941285 in sem_wait@@GLIBC_2.1 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
#2 0xb4ce7ec4 in ?? () from /usr/lib/libportaudio.so.2
#3 0xb4cd7ebb in Pa_StartStream () from /usr/lib/libportaudio.so.2
#4 0xb7f49518 in ?? () from /usr/lib/libopenal.so.1
#5 0xb7f2b7a3 in alcCreateContext () from /usr/lib/libopenal.so.1
#6 0x08074444 in hoa_audio::AudioEngine::SingletonInitialize() ()
#7 0x08054b75 in InitializeEngine() ()
#8 0x0805765d in main ()

Someone else has got problems with sound?

So, I ran this:
~/allacrost/trunk/demo$ ./allacrost --disable-audio
And the game came along nicely. Battles are tough, indeed.
And, yes, I confirm some flickering once in battle when using the battle menu.

Best regards.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Test of SVN snapshots

Postby Roots » Thu Mar 04, 2010 8:31 pm

I think someone popped into IRC a few days ago with sound problems. I wasn't active in the discussion but I believe I read something about PortAudio and OpenAL not playing nice together. We did get their problem fixed though. I think rujasu can help you out. He's running Debian unstable and I'm on Debian testing and audio has been working fine for us for many months. Its likely a library issue, since we haven't changed anything in the audio engine in quite some time.


Thanks for continuing to test and provide feedback on our snapshots. Its really nice to get continuous feedback and especially testing every few days. I'm going to see what I can do about the flickering issue at the end of battles. I might end up tearing that entire code apart though because its one of the last areas of the battle code that I have left mostly untouched :hack:
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Thu Mar 04, 2010 11:40 pm

Hi there,

Thanks for continuing to test and provide feedback on our snapshots.

:arrow: You're gladly welcome. I've got the easy part on this one.
And I'll try to keep testing on each viewable features or bug fixes.

Ah, and I saw you just managed to do a brutal combo :approve:

My best regards.

P.S.: Oh, and while I'm thinking about it, the forum's 'View active topics' doesn't seem to function. Is it on purpose?
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Test of SVN snapshots

Postby Roots » Fri Mar 05, 2010 12:06 am

Bertram wrote:P.S.: Oh, and while I'm thinking about it, the forum's 'View active topics' doesn't seem to function. Is it on purpose?


Hmm, i'm not sure why its not working. I'm pretty sure we didn't disable in on purpose. Good catch though. The "View new posts" seems to function alright.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Sun Mar 07, 2010 5:33 pm

AWESOME combo!

If roots gets to at least the 19th consecutive combo we'll get an ULTRA. XD
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Wed Mar 10, 2010 1:41 pm

Hi again,

Tested the SVN #1782 snapshot lately:

Compiling:
Little note: Adding -s and -Os options in the build options C::B is making a 3.79Mo binary (Hurray!)
But certain objects are still huge : src\modes\defs_modes.o is 60'967 Ko in size in release mode!
:arrow: Overheading or I'm missing some other things? :shrug:

Playing :D :
I tried the effects in battle and indeed, this is coming!
There a two very obvious things I noticed so far:
- The in battle damages and effects seem to be misaligned.
- It seems that the characters can't attack any more, but the Karlate Guard skill is working indeed, though.

Have a nice day everyone.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Test of SVN snapshots

Postby Roots » Wed Mar 10, 2010 2:24 pm

defs_modes contains most of our binding code, which uses a bunch of C++ metatemplate voodoo madness so it doesn't surprise me that it generates a large object file. Its also the file that takes the longest to compile for me on Linux.

I'm aware of the misalignment of battle damage and text. Some of the problem is with the code, but some of the problem is within the sprite images themselves. I'll be addressing this sometime int he near future. I've also had reports from other people that they couldn't attack with the characters. I'm not sure what's up with that and I've never experienced the problem myself, so it may require someone else who has the problem digging around and figuring out what is wrong. Generally speaking, you can't fix a problem that you can't reproduce. :angel: I have heard that someone who was reporting that problem no longer has the issue as of the latest commit, so who knows what's going on. :axe:


Thanks as always for the testing notes Bertram. :approve:
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Wed Mar 10, 2010 2:47 pm

Hi Roots,

- It seems that the characters can't attack any more, but the Karlate Guard skill is working indeed, though.


I just opened the stderr.txt and it lists many times these errors after a battling a bit from the welcome menu:

Code: Select all

.../demo\src\engine\script\script.cpp:HandleLuaError:81: a runtime Lua error has occured with the following error message:
 
dat/skills/attack.lua:185: attempt to call method 'ChangeSpriteAnimation' (a nil value)
.../\demo\src\engine\script\script.cpp:HandleLuaError:81: a runtime Lua error has occured with the following error message:
 
dat/skills/attack.lua:119: attempt to call method 'ChangeSpriteAnimation' (a nil value)
.../\demo\src\engine\script\script.cpp:HandleLuaError:81: a runtime Lua error has occured with the following error message:
 
dat/skills/attack.lua:141: attempt to call method 'ChangeSpriteAnimation' (a nil value)
.../\demo\src\engine\script\script.cpp:HandleLuaError:81: a runtime Lua error has occured with the following error message:
 
dat/skills/attack.lua:28: attempt to call method 'ChangeSpriteAnimation' (a nil value)

:arrow: Could be linked?
No I'm reading the errors, I realize that, yes, the characters don't change their animations while fighting. And it *could* be a bug, or just missing sprites...

At least, I hope it'll help.

Thanks as always for the testing notes Bertram. :approve:

:arrow: You, malicious flatterer ;)

Best regards.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Test of SVN snapshots

Postby Roots » Tue Mar 16, 2010 1:13 am

We've figured out the problem. If you upgrade your Luabind library to 0.9, it should work. The problem is that earlier versions of Luabind don't seem to assign class object types correctly when you have a derived class object being operated on in Lua. There's a work-around to get it to work with older versions of Luabind, but its kind of messy and I don't know if we're going to be adding it.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Tue Mar 16, 2010 8:00 pm

Hi Roots,

Thanks for the answer. Indeed, I confirm the battles are working when using libluabind-0.9.0, instead of libluabind0 for debian.
In fact, I had both installed and I had to remove the bad one to get this working.

I made a whole game test through the demo and here the results, again in my humble opinion:

First of all, I have to say that the music is very pleasant and well chosen so far. Everything can always be better but it's fine, really :approve: (Yes, I had the sound working just for one shot ;) )

Here are some little things that could be ""quickly"" (read: not in a too long time) fixed IMHO:
test.jpg
test.jpg (118.69 KiB) Viewed 7256 times


Again, the map fade out is too slow (the map fade in is fine), and it's not fps related. I mean you see the character reach the map's border and stick to it while walking and it's not really elegant (especially when quitting a map while moving diagonally).

Also, at the end, the characters should have the correct direction.
Kyle facing the captain, and Claudius facing them. (i don't know if it's feasible for now, though.)
test2.jpg
test2.jpg (45.74 KiB) Viewed 7256 times


Oh, and I'm not sure to understand what happens after the battle against Kyle :eyespin: .

So far, it's coming really fine :)
Congrats and good luck for what's next.

Best regards.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Test of SVN snapshots

Postby Bertram » Thu Mar 18, 2010 9:23 am

Hi again,

I also wondered with the current zoom if you maybe considered the fact of using some smooth rescaling,
just like 2xsal or such for maps and characters ?
http://en.wikipedia.org/wiki/Pixel_art_ ... algorithms

IMHO, this could keep the characters' proximity while polishing this game part without much efforts. :cool:

My best regards.

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 4 guests