dml wrote:Yep I agree the interlacing/pageflip thing looks terrible in emulators without messing around and sticking to fullscreen modes. On the one hand this is a really negative thing, but on the other - my 'policy' was to ignore emulation and deal with 'what was' as much as possible. In this case though, its problematic enough that its usefulness will be limited by emulation....
In Steem SSE, VSync can work in windowed mode, but the refresh rate must be appropriate.
A 60hz game will look much better on a 60Hz display.
That's the main problem with emulators.
This is true - it relies on good quality. I'm using lowish quality vids to make sure the tool works, but if doing this seriously I'd try to obtain HD and rescale the result with imagemagick or similar. Or try to record a playthrough myself in MAME (to video) and process afterwards. But really its meant as a prototyping time-saver, not as a way to make release-quality games. It's a shortcut to get things moving.
yes of cause strupid af me
but it is very impress to see what you already have achieved, one don't even notice that it is YT graphic.
dml wrote:
My tools do currently work using tilemaps - the extraction produces a tile library and a map to index it. The backgrounds are rendered during the game from these tilemaps. The tiles are also fuzzy-compared to help reduce duplicates (2 similar but not identical tiles can collapse into 1, based on some tolerance given on the commandline).
The size is currently fixed at 16x16 in parts of the code just because its efficient but the tools can produce other sizes.
thx i learned a new word today "tilemaps"
funny that i have had computer since around 82-83, and i did not know that it was call tilemaps, but it make good sence.
it is also tilemaps i will use, so it nice to hear that it's a good way to go.
dml wrote:
Collisions - I currently only have object-object collisions done. For object-background, I have just recently started working on it.
There are tons of ways to do it, but for various reasons i've settled on a 2-level system using a low resolution mask (is the object overlapping something interesting on the map?) and a detailed collision test, if the first test passes.
This makes testing of bullets vs background quick, which helps if there are lots of them. Most small things die or turn around when they hit something - so accelerating transitions over empty space is more important than the speed of the actual collision test. Checking huge objects against background can also be done this way, and the 1st test can be done in an analogue way that lets you shortcut the 2nd test for those.
But as I said - there are lots of ways to do this stuff with different pros/cons. This one should be quick and flexible but not really optimized for any one situation.
i have not made a finish game since that i had my Msx.
i started on many games for the ST, but after a while, i always started to code on other things, mostly chip / Midi trackers, so I never got around to do collisions on the ST.
but i also thinking something like the about, i am thinking on using a 5 bitmap where i copy the mask on from the level graphic / bullets ect. and then test with the mask from the Players Sprits.
i don't know if it is to slow but i am sure, that I will find out in due time
one more thing, since we had some of the same idea over time, i have to ask you if you ever have thought of this idea.
ok i was thinking of on how to make Outrun. and after i made the new import routine in ST-Paint, i came to the conclusions that outrun use way to many colors to make a good conversions.
so i got this idea, to make it for the STE, but in 16 gray scale, when it should be possible to get all of the right shades, of cuse it would look like you play it use a BW telly, but i think one could get it to look much closer to the arcade.
dml wrote:Yep I agree the interlacing/pageflip thing looks terrible in emulators without messing around and sticking to fullscreen modes. On the one hand this is a really negative thing, but on the other - my 'policy' was to ignore emulation and deal with 'what was' as much as possible. In this case though, its problematic enough that its usefulness will be limited by emulation....
In Steem SSE, VSync can work in windowed mode, but the refresh rate must be appropriate.
A 60hz game will look much better on a 60Hz display.
That's the main problem with emulators.
Hi Steven
if you know that the emulator is set to update every frame, you could add a filter that is doing like this.
that could maybe do the trick.
go down to my post, and also read the answer from dml. http://www.atari-forum.com/viewtopic.ph ... &start=350
Atari will rule the world, long after man has disappeared
sometime my English is a little weird, Google translate is my best friend
Finally got around to recording a Hatari vid showing project status properly, from my weekend hacks:
- tidied up the game (or what there is of it, so far - background collisions are 'pretend' for now)
- re-calibrated the music player down to 50hz for speed (it has been running at 200hz until now)
- finished & integrated the new PhotoChrome display code for splash screen support
- and of course...
The sample PCS splash screens do not mpeg too well because of the way they work with very subtle palette changes alternating over time - mpeg strips some of them out again, making the colours static/dithery/weird. But you get the general idea.
Note that PCS quotes 63 colours available per scanline. I have raised this from 52, due to some details I won't go into here! Scrolling is possible because all scanlines are encoded with the same timing pattern, including the bottom border transition.
Thanks everyone. I'll be working next on a first source release of the current source base. I'll go back to adding things later.
A word of credit also to Anima and his idea for EM sprites, which I also use here in this framework (although I have coded only a very basic version of it for now). It is one of many different parts involved but its an important one and turns out to be very useful. I'll be updating and adding more specific sprite options later for further speed improvements on different types of sprite.
Zamuel_a wrote:Do you have any demo I can run on a real STE? Had loved to see what it looks like on a real CRT monitor.
Yes, although I haven't compressed most of the assets yet - only the tune - so it won't fit on a normal floppy. If you have CFlash or CosmosEx it should run ok. (Otherwise I'll need to remove the samples dir and the splash screens).
WASD = fly up/left/down/right
RSHIFT = shoot
? = lock multiples in formation (when held)
@ = recall multiples back to ship (when held)
Some notes:
- there is no BG collision as mentioned before 'just pretend'
- you only have missiles when you use bullets. the other weapons don't give you missiles.
- I don't have a MegaSTE so compatibility is never certain. it should work though. if not, make sure it's running @ 8mhz.
- the AI was not made to cope well with reverse-scroll at the end of the level, this is an overhang from an earlier demo
- it jerks when the music changes, due to the depacker (temporary)
- the big pink blobs don't harm you if you collide with them (no its not a collision bug), but they do stop your bullets and do break up into nasties when they die!
- the enemies are not yet managed vs gameplay or time - allow too many to collect onscreen and it will slow down
I can't get it to work. I press DEMO1.TOS and after a few seconds it returns to desktop. I can see it writes out something unknown.... but since it return immediately I can't see what else it says. I tried it on both low and medium res. It's a 4Mb normal STE machine.
I tried it both from the USB memory connected to CosmosEX and from the internal HD.
Zamuel_a wrote:I can't get it to work. I press DEMO1.TOS and after a few seconds it returns to desktop. I can see it writes out something unknown.... but since it return immediately I can't see what else it says. I tried it on both low and medium res. It's a 4Mb normal STE machine.
I tried it both from the USB memory connected to CosmosEX and from the internal HD.
Ah the fun of software! Ok I'll take a look. It's supposed to write the machine type to the console then wait for a key. Maybe your machine/TOS is wrongly detected an unknown case. cookies! Do you have an unusual TOS btw?
[EDIT]
Yep - if it's an STF, or it can't make sense of the _MCH cookie (or can't find it) then it exits with a message. Forgot to add the wait-key to those cases. I can just make it carry on, assuming its an STE if the cookie is weird...
)
