Castaway.. Needs Auto-frameskip?


are you the guy that wrote it? if so, thanks a lot. i don't have my gp anymore but i had a lot of fun with castaway when i did.

personally i remember being happy with the frameskip how it was. what i didn't like was that it was persistently too dark, even if i changed the gamma/had the light on. don't know if you can fix that (or have fixed it already :eek: )
 
Not a huge need -- most things don't need any f/s (or keep it at 1), but if you feel like making it better, I'm sure that option would be appreciated :)

Great emu, btw -- thanks!
 
I say a big YES! it would make it soooo much better, and I wonder if it would help keep the music constant as it sometimes sounds like someones winding it up...

when yoyo added autofs to opensnes it made it much better

ps... erm... any chance you could enhance the gamma while your there? :p :p
 
frolik posted on Oct 28 2004 at 04:08 AM said:
I say a big YES! it would make it soooo much better, and I wonder if it would help keep the music constant as it sometimes sounds like someones winding it up...

when yoyo added autofs to opensnes it made it much better

ps... erm... any chance you could enhance the gamma while your there?  :p  :p

The gamma is perfect, for the BLU. Not sure about the rest. Maybe have an option for different settings, as long as the current setting is in there somewhere. I have noticed that settings made for the FLU/Nonlit look like shite on the BLU (grey backgrounds, washed out) and others that look great on the BLU (CaSTaway) are dark on the others. Could use settings for each I guess.

Also you probably wouldn't need frameskip if you added, well, you know... :)
 
Last edited by a moderator:
Auto frameskip would be cool, and yes, getting rid of the "Joystick" caption would be nice too. I must say that I was really impressed with the display etc when I got my BLU so don't muck about with the gamma, maybe put in an option for FLU users or something as I'm happy with it as it is on my BLU. The only other things I would say (and they ARE fussy) is that perhaps you could move the display down the sceen a few pixels as it begins right at the top where the screen frame sometimes shadows or obscures it, depending where you are playing it, especially on the FLU - and maybe style the popup keyboard to look a bit like an ST? They really are details though.

Great emulator, still discovering what it can do after all this time and it's never off the SMC...

®
 
Shirohagen posted on Oct 28 2004 at 09:00 AM said:
I must say that I was really impressed with the display etc when I got my BLU so don't muck about with the gamma, maybe put in an option for FLU users or something as I'm happy with it as it is on my BLU.
A gamma option for non-FLU/BLU GPs should be more important, right?
 
Last edited by a moderator:
Craig ;)

My issue is the same.. I worry about fdave's core; I know last time I looked at it it wasn't complete or correct enough to run TOS; its been numerous versions since, but its still not complete AFAIK .. ie: Consider GuineaPig and LJZ which can switch between C and ASM cores.. the C core will run more games, but the ASM will do them faster if it cna run them. And the ASM core runs most.

Is fdave still around? Someone mentioned awhil eback that he took picodrive/gp and cyclone off his website, and I think hes moved to symbian devving (though perhaps hes still updating cyclone for that platform, which would be good for everyone else too)

I need to bug fdave to get his current gp32 compatible cyclone version and see if she'd tie in, and see how much work it'd be to tie in; just last time it got killed day 1 when TOS did osme stuff it couldn't handle right :)

Anyone in contact with fdave these days?

jeff
 
I do need to look into a brightness function; the existing one was a cheap hack I think .. it was trying to be fast (per pixel colouring is tough to be fast on), but in the end dind't work out really well I guess; it worked out for the games I cared about ;)

I suppose when the emu sets various colour sin the palette, perhaps I should just alter what it sets, so that its not a per pixel calculation. If it sets a dark colour, I could use a lighter colour. The trick is trying to scale them all so it looks better.

ie: I was just bumping colours up in the palette; if its RGB, I just increased each up a notch.. as oyu can see, once things get closer to the top of RGB they go to *white* whichis why things tended to gray out.

If somethign is RGB(5,0,0) when it scales I guess it should stay as (7,0,0) perhaps and likely does.

But if something is RGB(5,2,2) and you scale it.. should it become (8,4,4) say? At this point you see the red brightened, but also the other guys so it starts to be reddy-gray I'd guess. PErhaps I'm scaling incorrectly.. I'll have to experiment.

--

As to position.. moving it down wouldn't work well; when you flip on the keyboard, it fits (barely) nicely under the emulated screen. It was a nice trick, so that the emu could run full speed. (Drawing a keyboard over the screen slows things down a lot of course). (Could do clipping tricks.. draw a larger keyboard on the screen, and clip the bottom of the screen.. but the wsa I do it now works for text adventures and everything, sinc none of the screen is covered)

--

I could remove "Joystick"; I put it there so you know what mode you're in; ie: If you're not in the standard mouse mode, it puts the mode name there. Removing it might be confusing. I could perhaps make it vanish after a second.

--

Auto frameskip could help in some cases; when the games are doing math, theres just not much you can do, since emulating the math is slow. But it woudl help withgames that are "nearly on time".

The trick of course, with the gp32, is figuring out the current clock; I need to look into that .. how many ticks per second, when the clock canbe set at any number of settings :)

jeff
 
so if you managed to incorporate Cyclone into CaSTaway, would you then consider implementing Hatari's sound core to solve the sound sampling?
 
skeezix posted on Oct 28 2004 at 01:07 PM said:
I do need to look into a brightness function; the existing one was a cheap hack I think .. it was trying to be fast (per pixel colouring is tough to be fast on), but in the end dind't work out really well I guess; it worked out for the games I cared about ;)

I suppose when the emu sets various colour sin the palette, perhaps I should just alter what it sets, so that its not a per pixel calculation. If it sets a dark colour, I could use a lighter colour. The trick is trying to scale them all so it looks better.

ie: I was just bumping colours up in the palette; if its RGB, I just increased each up a notch.. as oyu can see, once things get closer to the top of RGB they go to *white* whichis why things tended to gray out.

If somethign is RGB(5,0,0) when it scales I guess it should stay as (7,0,0) perhaps and likely does.

But if something is RGB(5,2,2) and you scale it.. should it become (8,4,4) say? At this point you see the red brightened, but also the other guys so it starts to be reddy-gray I'd guess. PErhaps I'm scaling incorrectly.. I'll have to experiment.

--

-

I...
jeff


If you are using the ST pallette to do the gamma then yes it would not work right. For example if something was shaded and it used 8,0,0 and 7,0,0 for two colors on the screen if you bumped the values up one they would BOTH be at 8,0,0 thus losing 1 color .

But if you use the GP32 pallette of 65,000 colors you could use some of the in-between color values as they would no longer be right next to each other in values like they were in the STs 512 color pallette. White would always be at the max level and the other values would be tightened up from there giving less steps between color values. black or color zero should always remain 0 value though. A common mistake I see made is that when gamma is adjusted they also increase black too giving a grey background. This washes out the look of the graphics.
 
Last edited by a moderator:
Back
Top