What is the feasibility of A Good Vector game in Mode 2 . Such as Asteroids , or Star Wars .Could someone explain The draw backs and Positives with this?
Well, IMHO, Mode 1 would be a better choice (square pixel), for example Starglider.
BTW. the Bollawares did some gamen in Mode 2.
I wondered whether you could get faster action in this mode ?
You can use sprite routines which are much faster. And yes, I mean that masked stuff that can move over the background ;)
So yes, you can get faster action. :)
Although the gain in speed is somewhat counterbalanced by the fact that you have to plot twice as many pixels to get the same width as in MODE 1. 8)
But it's a nice idea that I would like to see. Surely it's been done at least once on the CPC?
Vectrex emulator on CPC ? Wow... :o
Quote from: db6128 on 05:53, 20 January 13
Although the gain in speed is somewhat counterbalanced by the fact that you have to plot twice as many pixels to get the same width as in MODE 1. 8)
Ah no. If you would plot single pixels to plot a sprite, then you could make coffee between two frames ;)
It's done byte oriented, so it doesn't matter which Mode is set, because the width on screen is always the same.
Sorry, of course it is; what was I thinking? :-[ Somehow I didn't factor in the added bytes required to encode colours in the other modes.
And I definitely wouldn't think about plotting one pixel at a time—even the fairly fast plotting routines I've coded take a long time to fill a screen, so yes, plenty of time for beverages. :D
Quote from: TFM/FS on 23:34, 20 January 13
Ah no. If you would plot single pixels to plot a sprite, then you could make coffee between two frames ;)
It's done byte oriented, so it doesn't matter which Mode is set, because the width on screen is always the same.
I though he was talking about the line drawing routine and not the sprite routine.
No, (see his post before), but even drawing a line is much more easy in Mode 2, because you don't have to care about different colors (equals bit patterns). It's much more easy to set a bit instead of setting a bit pattern of a byte, when having nice routines for that especially ;)
However two colors is not much, if you work with shades and different colors in different parts of the screen it can become a great game though :)
It would be nice to see games like Tempest , Star Wars , Empire Strikes Back , which are great games in mode 1 but you can only go so far until the frame rate gets so sluggish that it makes the game unplayable, A nice fast Tron lightcycle game would be good also , with intelligent computer opponents.Take note any 16K developers ;) !
AI in 16 KB... :laugh: ... :P :P :P
;D Was I being over ambitious! Nevermind I am not a programmer. How much would you need to Incorporate reasonable AI in a Light Cycle game? Enjoy your Mock Doc! And give us some knowledge when you've finished.
I was bearing in mind , A light cycle game was developed which was impressive on a BBC Micro. And plus the fact i am hoping that someone would think of random events within the game that would be supplementary, to computer AI. :blank: [size=78%] [/size]
I realise this has little to nothing to do with AI
Just wanted to show a 16K game which looks fairly impressive Commodore 16/Plus4 - Tom Thumb - Longplay (http://www.youtube.com/watch?v=pEU2CXGiTBk#)
Classic Game Room - VECTREX MULTI-CART review (http://www.youtube.com/watch?v=XLson0x4_J4#ws)
not sure "vector graphic is that usefull on a much sich as the CPC which is completely bitmaped graphic mode.
I guess the Z80 being better than a 6502 at 3D could help?
Race car games used a few "vector" style tricks to get the road curves.
But I don't think Another World could be easily done on a real 8bit.
Vectrex uses an 1.5 MHz 68A09 (a 6809 but at faster clock).
The Thomson 8 bit MO/TO computers used a 6809E(1mhz only.
I've heard this 6809 is quite a good CPU for its time, quite better than the 6502, this 68a09 could most probably compete with a Z80B (the one at 6mhz).
Quote from: TFM/FS on 06:07, 22 January 13
AI in 16 KB... :laugh: ... :P :P :P
For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes. I'd be more worried about computational time, as ideally it has to fit in the time frame in which a screen will be updated.
Quote from: MaV on 10:43, 23 January 13
For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes. I'd be more worried about computational time, as ideally it has to fit in the time frame in which a screen will be updated.
Annoyingly the simplest light cycle AI pretty much makes an unbeatable opponent - the AI being "is there a wall ahead of me? Yes - choose a random direction to turn".
However you could have an AI that splits the screen up into 1/16s or something, and assigns a weight to each one based upon player occupation, and then tries to aim the cycle at low occupation areas and away from high occupation areas.
Quote from: Briggsy on 11:10, 23 January 13
Annoyingly the simplest light cycle AI pretty much makes an unbeatable opponent - the AI being "is there a wall ahead of me? Yes - choose a random direction to turn".
That makes for a pretty frustrating game, yes. The rule itself can be "softened" somewhat if it's connected to a few other simple rules. Say, for example the cutting rule above leads to the AI being "distracted". He also must not be distracted three pixels before a wall to make a proper turn. If he has been, he will crash into it. The cutting rule itself is activated whenever a player is very close. Combine that with perhaps a few other conditions and the AI will behave more human-like. And of course, the rules and their interactions need to be tested a lot. The next step forward would be to implement a proper finite state machine.
Since a lightcycle game is not graphics intense this still might be possible with 16k.
Quote
However you could have an AI that splits the screen up into 1/16s or something, and assigns a weight to each one based upon player occupation, and then tries to aim the cycle at low occupation areas and away from high occupation areas.
That's a good one!
Quote from: MacDeath
Vectrex uses an 1.5 MHz 68A09 (a 6809 but at faster clock).
Not sure why you're comparing with the Vectrex (I've got one, along with the Multicart, I just love that machine). Maybe there *is* some meaning in it, that I don't understand, but I'd expect that using a purely vector monitor has some advantages over vector 'emulation'...
Quote from: Puresox on 01:18, 23 January 13
;D Was I being over ambitious! Nevermind I am not a programmer. How much would you need to Incorporate reasonable AI in a Light Cycle game? ...
Well, first the 16 KB are not used up by the AI, I did express that wrong. But if you have a whole game inside 16 KB then this may not leave much RAM for AI.
Well 2 (hehe, couldn't resist ;) ), a pseudo AI which is based a bit on accident and a bit on 'move closer to opponent' and a bit on 'turn right / left if you approach a wall can be put into few KBs.
But a real AI which is able to follow a strategy - especially favorable on a Tron grit - takes definitely some more KBs.
Just imagine who much questions an AI has to pose every 'cycle' or 'turn', and how to integrate all that answers, and how to do it in an hirarchy (which you need, to make decidions), then you have different ways to react. Now he AI has to plan a bit ahead of time... Well, there is no end.
I did an AI for my Giana Sisters, but then I took it out of the game and saved a looooot of KBs that way.
And this AI was a real simple one though ;)
Quote from: MacDeath on 09:05, 23 January 13... this 68a09 could most probably compete with a Z80B (the one at 6mhz).
Yes it can try and loose :laugh:
Quote from: MaV on 10:43, 23 January 13
For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes.....
No, that's not that easy, think it thoroughly. To take your example, it's not only to cut off the player, it's also:
- Is there another player?
- Is there a wall?
- Is there a trace of the player or myslef?
- Is there the end of the grit?
Now integrate all that data and calculate a strategy. If you can do that in few hundred bytes you get the price ;D
But however, we've been talking about an AI, but we also see it's getting complicated quite quick.
Quote from: TFM/FS on 22:30, 23 January 13
Now integrate all that data and calculate a strategy. If you can do that in few hundred bytes you get the price ;D
By the time I wrote the second post, I was already thinking in kbs. ;)
Seriously, a lightcycle game is not a resource-hog, so if the game needs a generous 10kb, you'd still be left with 6kb for the AI, and that would make the game much more interesting (Those numbers are of course pulled out of my derrière, so who knows how much it'll actually be.)
Well, I see... the question here is when do you start to call something an AI. Or let's say how much IQ points are needed :laugh:
Actually it would be a cool project to code a multiplayer (maybe 4 gamers...) TRON grit game and all the players are AI's.
So everyone of us has ... let's say..... 8 KB of RAM and .... 10.000 ys for calculatons.
And the game is played by four AI's. So we let them fight for us.
I could do a simple game and define how the AI has to interact with the game. But then we would need some volunteers to write AI's. An AI contest :laugh:
Beware the birth of Skynet! :o
Quote from: steve on 02:17, 25 January 13
Beware the birth of Skynet! :o
Relax, I've already sent someone back in time to make sure that doesn't happen. What could possibly go wrong?!
Bryce.
Quote from: steve on 02:17, 25 January 13
Beware the birth of Skynet! :o
isn't that the name of the UK's spy satellite network?
EDIT: http://en.wikipedia.org/wiki/Skynet_%28satellite%29 (http://en.wikipedia.org/wiki/Skynet_%28satellite%29)
Then there's nothing to worry about... :P
(http://reseteados.com/wp-content/uploads/2010/06/moss.jpg)
Can someone explain the question posed earlier - whether a vector screen machine has some advantage over a raster one if you develop the same vecrot gfx?
Quote from: Gryzor on 13:39, 25 January 13
Can someone explain the question posed earlier - whether a vector screen machine has some advantage over a raster one if you develop the same vecrot gfx?
Well, for one, you don't need to clear the drawing area as the CRT sort of does that for you on every update of the screen. After all it displays only what you tell him to. Clearing the area for the vector graphics takes a good chunk of time on a bitmapped screen.
Then also no need to implement a line algorithm, since you only supply the coordinates for the lines and perhaps the colour of it for example.
The projection of 3d models onto a 2d plane is the same on both machines unless the vector graphics unit can do that as well (unlikely on retro boxes).
The disadvantage of a vector screen machine would be that you cannot display bitmaps or textures.
What I thought... yes, of course I know you can do bitmaps on a vector machine (well, if it's fast enough?), I was talking about speed :D
Also, I guess you forget the concept of monitor frequency, but I guess that since the beam skips most of it you can go faster than a normal 50KHz monitor, if the underlying hardware supports it?