> > What I ment was that you can't use vbl if you have got a Nova card as
> > you wont get a VBL interrupt, or will you? I don't realy know, but I
> > don't think the Nova interface can generate a vbl interrupt.
>
> In that case it'll break a lot of programs! I'm sure the VBL is still
> active even with Nova's installed.
It's of course possible that _a_ VBL interrupt is active, but it won't be the
"real" VBL interrupt unless there is a way to get that from the NOVA card
and onto the original interrupt line, which seems doubtful.
> > Oppss... sorry. I ment, as long as it's not a fast scrolling game I see no
> > reason why you should not use GEM. :-)
>
> What you *really* ment was that as long as you're using a f**kin' fast
> CPU there's no reason not to write fast scrolling games in GEM ;-)
I think the lack of fast double buffering is the main problem. There is no
way to instantly switch to a new predrawn screen if you're running in a
window, no matter how fast your processor is (ST-RAM access is slow).
A graphics card might be able to do a fast enough blit, though...
Apart from that, there's nothing stopping you from writing directly to screen
memory even under GEM (except hardware dependence, of course) and blitting
without shifting or changing graphics format is actually very quick with NVDI.
> > > And if it doesn't use GEM directly (i.e. use windows and stuff), it
> > > should be quite possible to make it work with GEM, perhaps with a
> > > hotkey to switch back to GEM during playing.
> >
> > Yes, but fast scrolling games is harder to do. PAC-Mans and such stuff is
>
> That's why you should use your own/custom-written screen-routines, and
> not run things in on the VDI/AES-screen at all. But if you could just
Wasn't the idea to have games working on things like NOVA boards?
Then you have no way of switching to the standard screen modes required.
> GEM-games are fine (there's a lot of games I would like to see running
> in a window), but for Really Good Games (i.e. good graphics, smooth
> animation/scrolling) nothing beats custom-written code.
Actually, an action game could be a lot faster if it used GEM on a card
where the scrolling and blitting is done by good hardware...
(There's still the possible problem with double buffering, though.)
> > I guess there is no way to patch some games to run in a GEM window,
> > like Popoulus?
Why not?
With a processor that supports an MMU, I don't see any problem with that,
in principle.
With proper memory space setup, it should be quite possible to fool a program
into believing that it's accessing the normal screen and then have another
task responsible for converting that for display on the real screen.
If necessary, even most hardware accesses could be trapped and emulated via
GEM etc.
I think a scheme like that could be made to work rather well, but I don't
think anyone's ever going to give it a try.
> > BTW. Has anyone tried Popoulus on the AB040? I would realy like to play
> > it if it works.
>
> Doubtful. The only game I've partly managed to run on the AB is "No
> Second Price". It worked, but the gameplay was interrupted constantly
I've not tried that many games, but I was surprised at how many did work fine.
If there was an equivalent of Backwards for the AB040, I think lots of things
would work well.
> with a "sure you want to quit?"-alert. Let's install Geir's
Sounds like the MOVEM problem to me (I had similar problems with Frontier).
Have you tried disabling one or both caches?
--
Chalmers University | Why are these | e-mail: rand_at_cd.chalmers.se
of Technology | .signatures | johan_at_rand.thn.htu.se
| so hard to do | WWW/ftp: rand.thn.htu.se
Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)
Received on fr. sep. 26 1997 - 14:41:00 CEST