 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
msw188
Joined: 02 Jul 2003
Posts: 1041
|
 Posted: Sat Mar 18, 2006 8:50 am Post subject: |
 |
|
Should I put this midi looping thing in Bugzilla? This seems a pretty major problem to me, in that it essentially breaks all backwards compatability. Any game ever released with music is affected, no?
What is music_native? Can it run with the OHR, or is that what you guys are discussing? |
|
| Back to top |
|
 |
PlayerOne
Joined: 07 Sep 2005
Posts: 143
Location: UK
|
| Posted: Sat Mar 18, 2006 9:34 am Post subject: |
|
|
| msw188 wrote: | | Should I put this midi looping thing in Bugzilla? This seems a pretty major problem to me, in that it essentially breaks all backwards compatability. Any game ever released with music is affected, no? |
It will only affect BAMs which do not loop back to the start (and even then how much of a difference it makes will depend on the nature of the piece of music). I don't know what percentage of BAMs that will be, but it is far from all of them. To some extent it is an inevitable consequence of not being able to play BAMs in Windows/Linux.
It is a known issue. I'm not sure if it needs to be logged in Bugzilla or not. Perhaps it should. I know I'm often guilty of not logging problems I know about.
| msw188 wrote: | | What is music_native? Can it run with the OHR, or is that what you guys are discussing? |
Sorry, music_native is just one of the source files that is already part of FB Game. Previously we were using external libraries for MIDI playback (via music_sdl and music_allegro) which did not give us very much control over the looping. With music_native, we are playing the MIDI files ourselves, and potentially have all the control we need, but (see the post before yours) there might still be some serious issues with it on some systems.
The FreeBasic version is written so that it is relatively easy to add a new graphics or music module, hence the multiple versions in the nightly builds. Most of them, sadly, have some issues somewhere, so it's very difficult to make a decision as to which should be official. Tirgoviste uses "FB2" graphics and "native" music, in Windows. |
|
| Back to top |
|
|
Jjkaybomb
Brunettes have more hair
Joined: 04 Sep 2003
Posts: 267
Location: Hunting with the mouse
|
| Posted: Sat Mar 18, 2006 1:54 pm Post subject: That music's screwed up... |
|
|
Yeah, something's wrong with the music part of the update, whenever I flip fast through the music section of custom.exe, it will randomly shut off with no warning. Sorta relates to JSH's problem, there's something wrong with the music section with allowing both formats.
_________________
A man once said to the Universe "Sir! I exist!"
"However," replied the Universe, "This does not create in me a sense of obigation."
~Stephen Crane |
|
| Back to top |
|
|
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
| Posted: Sat Mar 18, 2006 3:14 pm Post subject: |
|
|
Also: Ctrl+F doesn't work in the map editor in Allegro... or was it FB2? Or maybe all of the Windows CUSTOMs?
I'll do some checking on this later.
_________________
|
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Mar 20, 2006 8:24 am Post subject: Re: allegro |
|
|
| Mike Caron wrote: |
Let's put it this way... anywhere where you should be playing the OHR, you should also have root access. Work and school are not such places ;) |
Boo! Never run games as root! Ever! Bad Mike! *rolls up a newspaper*
| Pepsi Ranger wrote: |
Anyway, having said all that, I discovered a huge difference between the QB version and Windows version of GAME. In Tightfloss Maiden, there's a level that requires several scripts to be accessed at once through an each-step script. The QB version handles it smoothly (for the most part), but the Windows version runs like utter crap on this level. Thought you guys might like to know that in case there are some clocking or processing issues you still have to work through.
If you need more information, picture this:
In the QB version, the character walks wherever the player sends her without much noticable hesitation. While this happens, the "each-step script" is accessing a footprints script, a random enemy script, a dehydration script, and an auto-kill script, and does so at a fast enough pace to keep the game running nicely.
In the Windows version, however, all these scripts are still getting accessed at each step, but now the character looks like she's testing every movement for landmines (pausing for nearly two seconds between each tile advancement).
This difference in accessing speed might be worth looking into.
If any of you need a test file, let me know and I'll email it to you. |
Yes, I would like to see a testcase of this. Can you file this as a bug, please?
| JSH357 wrote: | | Negative damage appears to be dealing, well, negative damage for me. (As in, it's healing the target) Other than that, I haven't noticed any new bugs. |
Can you file a bug on this? I would like to see a testcase with an attack that behaves correctly in game-qb.exe but does not in game.exe
| JSH357 wrote: |
Edit:
HOWEVER, once again, game.exe has started crashing at completely random intervals. I have no way to reproduce this bug, but what happens is the program just closes out of the blue. No error message, no big unreadable letters, no nothing. Program just closes.
Really, I'm getting kinda fed up with this.
Edit 2:
OK, I've narrowed the crashing down some. It APPEARS to be happening after playsong() commands, and apparently the problematic songs are the BAMs being converted to MIDI by the engine. I'm going to try using stopsong() before playsong(), but since it's still crashing RANDOMLY, I have no idea if this will help at all. |
This sounds like another manifestation of bug 163. The music crash is easiest to reproduce in the music import screen because so many songs are played and stopped so fast, but I am sure this bug can happen anywhere, as you are seeing. |
|
| Back to top |
|
|
RedMaverickZero
Three pointed, red disaster!
Halloween 2006 Creativity Winner
Joined: 12 Jul 2003
Posts: 1459
|
| Posted: Mon Mar 20, 2006 9:05 am Post subject: |
|
|
| I have tested my new game in tirgovista and the rewards don't show up after a battle. However, in older games they do. When I played the same game in the older version of ohr everything worked fine. |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Mon Mar 20, 2006 11:13 am Post subject: Re: allegro |
|
|
| James Paige wrote: | | Mike Caron wrote: |
Let's put it this way... anywhere where you should be playing the OHR, you should also have root access. Work and school are not such places  |
Boo! Never run games as root! Ever! Bad Mike! *rolls up a newspaper* |
But, that is why we can't use FBGFX on linux, is it not? It needs root permissions?
| James Paige wrote: | | JSH357 wrote: | | Negative damage appears to be dealing, well, negative damage for me. (As in, it's healing the target) Other than that, I haven't noticed any new bugs. |
Can you file a bug on this? I would like to see a testcase with an attack that behaves correctly in game-qb.exe but does not in game.exe |
Correct me if I'm wrong, but shouldn't negative damage heal the target?
| James Paige wrote: | | JSH357 wrote: |
Edit:
HOWEVER, once again, game.exe has started crashing at completely random intervals. I have no way to reproduce this bug, but what happens is the program just closes out of the blue. No error message, no big unreadable letters, no nothing. Program just closes.
Really, I'm getting kinda fed up with this.
Edit 2:
OK, I've narrowed the crashing down some. It APPEARS to be happening after playsong() commands, and apparently the problematic songs are the BAMs being converted to MIDI by the engine. I'm going to try using stopsong() before playsong(), but since it's still crashing RANDOMLY, I have no idea if this will help at all. |
This sounds like another manifestation of bug 163. The music crash is easiest to reproduce in the music import screen because so many songs are played and stopped so fast, but I am sure this bug can happen anywhere, as you are seeing. |
Damnit, someone mail me their PC so I can freaking reproduce this bug... 
_________________
I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Mar 20, 2006 12:48 pm Post subject: root |
|
|
| Mike Caron wrote: | | James Paige wrote: | | Mike Caron wrote: |
Let's put it this way... anywhere where you should be playing the OHR, you should also have root access. Work and school are not such places ;) |
Boo! Never run games as root! Ever! Bad Mike! *rolls up a newspaper* |
But, that is why we can't use FBGFX on linux, is it not? It needs root permissions?
|
No, fbgfx works on linux as a regular user, but full-screen support is really flakey. On some systems it will just move the game window to the top left corner of the screen, and on other systems it will resize the screen correctly but then fail to restore the original resolution when it exits. This is really more of an X-windows problem than a linux problem.
SDL is the most reliable way of getting full-screen support in Linux games. There is no technological reason why FB's screen-mode handling can't someday be as good as SDL's, it just simply isn't right now.
As for root access, some old linux games used to require you to run as root so they could directy access the video card in a DOS-like way, but I am not aware of any actively developed games that still recomend that. All of them have ported to either SDL or OpenGL. |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Mon Mar 20, 2006 12:53 pm Post subject: |
|
|
I think Allegro still does that, so any games devel.... but, I digress. SDL. Yeah. Is the graphics component of SDL as... shall we say... "high level" as SDL_mixer?
_________________
I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Mar 20, 2006 5:45 pm Post subject: |
|
|
| Mike Caron wrote: | | I think Allegro still does that, so any games devel.... but, I digress. SDL. Yeah. Is the graphics component of SDL as... shall we say... "high level" as SDL_mixer? |
Heh, not that high level. I think that if a graphics API was as high level as SDL's music API, it would look something like:
| Code: |
SDL_Display_All_Graphics_Now()
|
|
|
| Back to top |
|
|
JSH357
Joined: 02 Feb 2003
Posts: 1705
|
| Posted: Mon Mar 20, 2006 6:24 pm Post subject: |
|
|
| The damage bug seems pretty simple to me. When my hero's defense is so high that enemies are technically doing negative damage, it isn't converting to 1 anymore. |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Mon Mar 20, 2006 7:22 pm Post subject: |
|
|
| James Paige wrote: | Heh, not that high level. I think that if a graphics API was as high level as SDL's music API, it would look something like:
| Code: |
SDL_Display_All_Graphics_Now()
|
|
Gotcha. Of course, I think I could learn to live with an API like that, or more realistically, like this:
| Code: |
dim playing as integer
playing = 1
do while playing
playing = Do_Game()
Draw_Stuff()
Frame_Limit()
loop
|
That would be the ultimate game programming library ^_^
| JSH357 wrote: | | The damage bug seems pretty simple to me. When my hero's defense is so high that enemies are technically doing negative damage, it isn't converting to 1 anymore. |
Ah. No. It doesn't wrap around anymore. It goes like this (in pseudo code):
| Code: | if damage > 15^2 - 1 then damage = 15^2 - 1
if damage < -15^2 then damage = -15^2
if damage > damage cap then damage = damage cap
if damage < -damage cap then damage = -damage cap |
And, all this is done with a variable that's overly huge, so there's no possibility of it overflowing (wrapping around) at all.
So, if an enemy does negative damage, it really will heal the target. On the other hand, if the "Allow Damage to be 0" bitset it off, it will cap it at minimum 1.
Edit, after reading the whole post:
Hmm. The only reason I can think of that would happen is if the "Allow Damage to be 0" is off, in which case no capping is done (I forget if it caps it at 0, or if it doesn't cap at all...)
_________________
I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Mar 20, 2006 10:12 pm Post subject: |
|
|
| Mike Caron wrote: | | James Paige wrote: | Heh, not that high level. I think that if a graphics API was as high level as SDL's music API, it would look something like:
| Code: |
SDL_Display_All_Graphics_Now()
|
|
Gotcha. Of course, I think I could learn to live with an API like that, or more realistically, like this:
| Code: |
dim playing as integer
playing = 1
do while playing
playing = Do_Game()
Draw_Stuff()
Frame_Limit()
loop
|
That would be the ultimate game programming library ^_^
|
That is not too far away from what you can do with pygame |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Wed Mar 22, 2006 5:14 am Post subject: |
|
|
I have found two more problems, although they may simply be more symptoms of problems mentioned before. First, music can get messed up in game.exe in the following manner: if you go through a door that does not change the ambient music, 'sometimes' the voices are replaced with pianos. Actually, I have only been able to reproduce this on maps using song number zero, that also have map autorun scripts. Nowhere else, but it happens fairly often on those maps when you go through a door. However, once there is a rest for the affected instrument, it seems to successfully turn back to its correct voice.
The second problem is really just another complaint about the keyboard handling. It seems that the CTRL button is read incredibly fast, so that it is nearly impossible to press it without it being interpreted as being pressed at least twice. None of the other buttons seem to have this problem (actually, by 'other' I only mean the space bar, the ALT key, ESC, and the debugging keys). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
