| Age | Commit message (Collapse) | Author |
|---|
|
Inventory".
This patch corrects the valgrind fault, but may not be the ultimate fix.
This should be reviewed before backport to v1.1.0 branch.
svn-id: r48434
|
|
svn-id: r48359
|
|
svn-id: r48287
|
|
svn-id: r48279
|
|
(fixes bug #2907954: "DRAGON: Crash in Intro")
svn-id: r48147
|
|
engines + GUI and proper keypad handling
svn-id: r48101
|
|
svn-id: r48027
|
|
svn-id: r47716
|
|
sound/decoders/
svn-id: r47579
|
|
svn-id: r47541
|
|
svn-id: r47492
|
|
svn-id: r47397
|
|
svn-id: r47395
|
|
Mixer::playRaw to Mixer::playInputStream
svn-id: r47375
|
|
Also fix several recently introduced new/delete vs. malloc/free mismatches.
svn-id: r47369
|
|
/ company.
Check this for reference:
http://en.wikipedia.org/wiki/Ad_Lib,_Inc.
http://www.crossfire-designs.de/images/articles/soundcards/adlib.jpg (note the upper left of the card)
This commit does not touch "adlib" and "ADLIB" uses!
Also it does not update all the SCUMM detection entries, which still use "Adlib".
svn-id: r47279
|
|
svn-id: r47215
|
|
This makes sense as a default for CLUT8 modes, but not really
for anything else. As part of the gsoc2009-16bit merge, the
default was changed to "all ones", with extra code in the SDL
backend to truncate this to the depth of the mode. However,
"all ones" (white) still isn't a very useful default for RGB modes.
So rather than jumping through hoops to provide a bad default,
it's better to remove the default altogether. Engines which relied
on the old default of 255 have been updated to specify it explicitly.
svn-id: r47118
|
|
svn-id: r46326
|
|
svn-id: r46323
|
|
svn-id: r46320
|
|
svn-id: r46316
|
|
svn-id: r46299
|
|
like megath just did in the TeenAgent engine.
svn-id: r46284
|
|
without it (at least with Symbian OS GCCE 3.4.3 and CW 2)
svn-id: r46213
|
|
It seems that the mouse was simply on the below line and triggered the switch
to the map without the user realizing.
svn-id: r46171
|
|
It was caused by forever re-starting the same sample when the animation was
stopped and the same frame got displayed over and over, each time triggering
playing the same sample.
svn-id: r46168
|
|
svn-id: r46142
|
|
without details; help filling these out is welcome)
svn-id: r46128
|
|
svn-id: r46117
|
|
not enough)
svn-id: r46101
|
|
Last commit moved it below, but that cancelled GPL2 programs run right
after loading the game.
svn-id: r46099
|
|
I have tested that this could only possibly happen when the game has been
loaded with last location being the map. Then pressing Escape calls
enterNewRoom() and this superfluous optimization takes place. It is harmless
to simply reload the map. After having removed it, enterNewRoom() needs not
return any return value, because the test at the tail can be done by the
caller. I have then restructured the code a little to make it cleaner.
svn-id: r46098
|
|
Now only a long-term (complete rewrite) TODO is left in the code, but nothing
urgent to solve.
svn-id: r46097
|
|
(otherwise we could have in our hands an unreachable object). This works
thanks to moving clearing _currentItem into putItem(), which gets called
in inventoryReload().
svn-id: r46096
|
|
Verified that we really do not need object animations even if they are in
a different location, and clearing them thus regardless of their location.
Although the game was not crashing due to previous work-arounds at this
moment, this cleanup obliterates the most horrible hack and makes sure
animations will never get stale.
svn-id: r46095
|
|
Now the game seems fully playable with crazy loading all the time, even
though it is a hacky solution. Updated the TODOs
svn-id: r46094
|
|
svn-id: r46070
|
|
I have thoroughly documented why this hack is needed and added ideas how to
fix it properly.
svn-id: r46068
|
|
svn-id: r46059
|
|
(otherwise the relative animation would repeat itself unhandled until the
hero disappears from the screen.)
svn-id: r46058
|
|
With the previous code, the position of the animation was doubled (due to
counting the position twice, the second time being a relative shift), which
put it mostly outside the screen. This is because one-time hero animations
are actually stored using absolute coordinates.
svn-id: r46057
|
|
It does not return kTitleText and others. This caused flickering of speech
texts on/off when the title got displayed under the mouse.
svn-id: r46056
|
|
svn-id: r46044
|
|
svn-id: r45876
|
|
svn-id: r45874
|
|
svn-id: r45873
|
|
svn-id: r45872
|
|
svn-id: r45855
|
|
svn-id: r45851
|
