Doesn't this on C64 remember us of some demo we have on A8?

[José Pereira]

Just saw this:

Have they been seeing something we have for years?

Hummm... that Mario cart we could do with ours PMGs right?

What about a Mario kart game?

Edited April 3, 2019 by José Pereira

[emkay]

Good grieve.

People blame games for some blocky charmode movement, this game seems to use the same mode as in MOOD. The vertical resolution is doubled.

On the Atari , you may find people blaming the 4x4 mode already.

As the game is rather "flat" , the solution for 4x4 mode with any GTIA overlay would look stunning.

The Protagonist isn't big, too. So PMg would help there.

[José Pereira]

I count it 10pixels wide so having 2 players and 2 zones similar to Trailblazer.

Problem is the way A8 works in GR.10.

PM0 be black (02) is good because is also the border colour and PM1 red (38) then oring multicolour light (3A) for Mario's skin.

The other player has to 'waste' PM2 same black (02) and PM3 green (C8) then oring (CA) and is a green skin creature (maybe from Mart ).

Not bad that you'll have 8colours on the 4:1 ratio pixels gfxs and two more on the PMGs multicolour.

[Gunstar]

I was just thinking about a kart racing game on the Atari myself a day or two ago! I was imagining something like Ballblazer but with race tracks...

[emkay]

I was just thinking about a kart racing game on the Atari myself a day or two ago! I was imagining something like Ballblazer but with race tracks...

I wonder how it looks, using gr. 11 with black outline on the objects. For the Background, GR.10 would be nice.

[José Pereira]

On A8 it would look better GR.10 with gfxs in 4:2 ratio (4:4 is probably too blocky) and then guys sprites PMGs 2:2 fit better.

Edited April 3, 2019 by José Pereira

[emkay]

On A8 it would look better GR.10 with gfxs in 4:2 ratio (4:4 is probably too blocky) and then guys sprites PMGs 2:2 fit better.

Erm... on the C64 it is 8x4 (compared to the A8 modes) . And the C64 doesn't need complex and CPU using routines for the "sprites".

So on the Atari you want 4 times more graphics content AND the extra in PMg usage.

 

4x4 would be 2 times better already.

[+MrFish]

Just saw this:

 

Man, that looks terrible (except for the kart). I wouldn't even be interested in playing something as low res and jerky as that.

[Gunstar]

 

Man, that looks terrible (except for the kart). I wouldn't even be interested in playing something as low res and jerky as that.

I agree, but I think the Atari could do better, whether the same approach or something different, like I mentioned with a graphic engine something like Ballblazer...or even on a pole position like track. I don't think a 360 degree "play area" is necessarily needed for a kart like game, but if so, I think our 1.79Mhz Atari's with all it's special graphic modes (especially GTIA ones) could do higher-res and much better frame rate.

[emkay]

That's why I brought Gr.11 in. The color dither would help much against the blocky look. Only for some needed details, black could be used.

With some trickery, some Player could be used for the white tiles of the starting line.

[José Pereira]

There's always GR.9 (and even GR.15 better resolution) having colour and grays in intercalating scanlines though it'll only look good on PAL.

[emkay]

There's always GR.9 (and even GR.15 better resolution) having colour and grays in intercalating scanlines though it'll only look good on PAL.

Now it's getting boring.

Guess WHY it is using that low resolution on the C64 . One clue : It is not caused by their taste for blocky graphics.

[+MrFish]

I agree, but I think the Atari could do better...

 

Yeah, it'd be interesting to see what the Atari could do with it. But, unless we're just talking about a one car demo again, you'd at least need some way of rendering some other hi-res-ish sprites.

 

[Edit] At least the sprites aren't very wide, which would be good for the Ataris, compared to needing large cars in most racing games.

 

This brings up something else, why not work on a motorcycle game as an alternate, for the same reason...

Edited April 3, 2019 by MrFish

[emkay]

The engine is doing ~ 10fps for 360Degree rotations.

Heck, how could it be done to get those cool coders doing that stuff for the Atari?

[solo/ng]

looks weak

[Kyle22]

I was just thinking about a kart racing game on the Atari myself a day or two ago! I was imagining something like Ballblazer but with race tracks...

 

Trackblazer?

[Rybags]

It's doing what seems to be "proper" 3D raycasting though the trees at the horizon are traditional scrolling background stuff, same for sky object. Then again modern day games do similar - Far Cry used sprites for objects further than a certain distance and virtually everything does the sky with simple textures without much or any 3D processing.

 

It's good but the problem I foresee is that once you throw in physics and game processing overhead you'll get the obvious slowdown just in that 80x40 or whatever viewport, and doing a 2P game with human or computer opponent will probably turn it into a slideshow.

[emkay]

It's doing what seems to be "proper" 3D raycasting though the trees at the horizon are traditional scrolling background stuff, same for sky object. Then again modern day games do similar - Far Cry used sprites for objects further than a certain distance and virtually everything does the sky with simple textures without much or any 3D processing.

 

It's good but the problem I foresee is that once you throw in physics and game processing overhead you'll get the obvious slowdown just in that 80x40 or whatever viewport, and doing a 2P game with human or computer opponent will probably turn it into a slideshow.

It seems to work already as a racing game. There is reaction to the ground. It slows down on the "green" and it shows splashing on the water.

But it "looks weak" as written above

 

Actually it looks great and would be a great game... on the Atari

Edited April 4, 2019 by emkay

[Rybags]

Multiple benefits to be had on Atari - you're not stuck with divisors of 2 for the vertical resolution.

It'd look better with 3 pixel height instead of 4 - and if sufficient CPU cycles are left, there could be 2 then 1 pixel height at further distance.

That has an added side-effect that it might enhance the perspective for free.

 

Regardless, it would be nice to see a car game on either machine that uses actual 2.5D rendering techiques rather than the existing "cheating" methods.

[Wrathchild]

Mode 7 projection should be fairly straight forward to optimise at the resolution they're working at.
Having already gone through and online explanation here, combined with study of emulator sources, I'd come up with this for the UNO cart prototype (gr.15):


Initialised with: space_z = 120.0, scale_x = 200.0, scale_y = 200.0, horizon = 80

void vram_mode_7(ALLEGRO_BITMAP *buffer, int angle, float cx, float cy)
{
    unsigned char c;
    ALLEGRO_COLOR cols[4] = {
        al_map_rgb(104, 104, 48),
        al_map_rgb(176, 168, 72),
        al_map_rgb(240, 240, 120),
        al_map_rgb(0, 0, 0)
    };
    ALLEGRO_BITMAP *tile;
 
    // the distance and horizontal scale of the line we are drawing
    float distance, horizontal_scale;
    // step for points in space between two pixels on a horizontal line
    float line_dx, line_dy;
    // current space position
    float space_x, space_y;
    // masks to make sure we don't read pixels outside the tile
    int tile_x, tile_y;
    int pixel_x, pixel_y;
    // current screen position
    int screen_x, screen_y;
 
    al_lock_bitmap(buffer, ALLEGRO_PIXEL_FORMAT_ANY, ALLEGRO_LOCK_WRITEONLY);
 
    for (screen_y = 0; screen_y < SHEIGHT; screen_y++)
    {
        // first calculate the distance of the line we are drawing
        distance = (params.space_z * params.scale_y) / (float)(screen_y + params.horizon);
        // then calculate the horizontal scale, or the distance between
        // space points on this horizontal line
        horizontal_scale = distance / params.scale_x;
 
        // calculate the dx and dy of points in space when we step
        // through all points on this line
        line_dx = -sinf((float)angle*_2PI) * horizontal_scale;
        line_dy = cosf((float)angle*_2PI) * horizontal_scale;
 
        // calculate the starting position
        space_x = cx + (distance * cosf((float)angle*_2PI)) - ((SWIDTH / 2) * line_dx);
        space_y = cy + (distance * sinf((float)angle*_2PI)) - ((SWIDTH / 2) * line_dy);
 
        // go through all points in this screen line
        for (screen_x = 0; screen_x < SWIDTH; screen_x++)
        {
            if (params.horizon < 0 && screen_y < (-2 * params.horizon))
            {
                c = 3;
            }
            else
            {
                tile_x = ((int)(space_x) >> 3) & (MAPSIZE - 1);
                tile_y = ((int)(space_y) >> 3) & (MAPSIZE - 1);
 
                tile = get_tile(tile_x, tile_y);
 
                pixel_x = (int)(space_x) & (TILESIZE - 1);
                pixel_y = (int)(space_y) & (TILESIZE - 1);
 
                // get a pixel from the tile and put it on the screen
                c = get_pixel(tile, pixel_x, pixel_y);
            }
            al_put_pixel(screen_x, screen_y, cols[c]);
 
            // advance to the next position in space
            space_x += line_dx;
            space_y += line_dy;
        }
    }
 
    al_unlock_bitmap(buffer);
}
 

I'd hazard a guess that the Race7 uses a single tile to define the whole track however one using multiple tiles, say 32x32, would help with the game engine knowing what was where, e.g. water, track, grass etc.

Edited April 4, 2019 by Wrathchild

[José Pereira]

Ok. So instead 0f C64 that has 8x4 size pixels we could go for what, 4x2?

The top on the trees, clouds and sky we could do in what, GR.7 2x2? GR.15 2x1 or is possible/better charmode GR.13 2x2 or in GR.12 2x1 pixels size?

 

But regarding playing area I tried to see what colours we could have for gfxs paying attention that using GR.10 we still need to share some of them with the karts.

If, like Trailblazer, that they can the two meet eachother then these bars at the bottom are the colours we can have (just aproximate ones not real A8 doing quickly using PAINT):

704 (for gfxs and Mario PM0 but also the borders): darkest gray (02);

705 (for gfxs and Mario PM1): red (38);

(On the left the PM0 oring PM1 only on Mario frames and not on gfxs gives a pink (3A))

706 (for gfxs and the top creature PM2): darkest gray (02) ;

707 (for gfxs and the top creature PM3): green (B8);

(On the left the PM2 oring PM3 only the creature frames and not on gfxs gives a light green (BA))

708 (only on gfxs): a blue for the water;

709 (only on gfxs): the light brown;

710 (only on gfxs): the dark brown;

711 (only on gfxs): the white;

 

From C64 the only majour colour we're missing is a purple/lilac but we really need to have repeated that darkest gray (black) for the two wheels.

The karts on C64 that are 12pixels wide should be reduced (or maybe not...) to 10pixels wide (and I also think they'll look better to be in 2x2 size so they don't be too small VS large gfxs pixels...).

I put white as PF3 colour register in case is a single player game or even with the two windows they're at different worlds (so not meet eachother) and then the kart can, for each, be wider (and taller...) so the white can be used as the 4MISSILES in 5th PLAYER mode (for that splashing effect when in the water).

This way 2 registers (this time P0_704 and P1_705) have to still be the same darkest gray (black), but we could, maybe then have P2_706 red Oring P3_a gray will give the pink (so they'll look similar to C64) on mario (red replaced by green on the creature would Oring with gary still gives a light green):

Get it?

Edited April 4, 2019 by José Pereira

[emkay]

Get it?

Is it possible, you don't get it at all?

The game doesn't use any raster trick. Neither the C64 nor the Atari has a 3D depth rotating hardware.

 

I'd like to see such a 3d rotating game platform on the Atari, using Gr. 11. And, OF COURSE, the resolution of 8x4 or 4x4 is even on the Atari, the way to go.

I suspect that the C64 has heavy fps drop when both screens /player move.

[Wrathchild]

The game doesn't use any raster trick. Neither the C64 nor the Atari has a 3D depth rotating hardware.

I don't think Jose claimed that?

 

If someone can make me a tilemap using Mappy (save as fmp) then I can knock together a preview.

I'd suggest 32x32 or 64x64 with either a 16 colour map (using gr.11 colours) or a selection of just 9 (simulating a gr.10 selection from the A8 palette), so tiles can be 8x8 but if you can fill them to look like 2x2 or 4x4 if you like.

 

9 colour Gr.10 can look nice

 

Edited April 4, 2019 by Wrathchild

[emkay]

I don't think Jose claimed that?

Yeah. The C64 has hard times with that 8x4 mode, and the Atari will do it with a 4 times higher resolution.... for sure

 

If someone can make me a tilemap using Mappy (save as fmp) then I can knock together a preview.

I'd suggest 32x32 or 64x64 with either a 16 colour map (using gr.11 colours) or a selection of just 9 (simulating a gr.10 selection from the A8 palette), so tiles can be 8x8 but if you can fill them to look like 2x2 or 4x4 if you like.

 

Gr.9 can look nice

 

OK. This Video shows the "Axelay" scrolling, somehow.

But the engine shows 360 Degree rotations. This is something, that should be "normal" on the Atari, but, again, they did it on the C64 first.

[Wrathchild]

But the engine shows 360 Degree rotations.

Only as it doesn't make sense to rotate that particular scene, its the same engine as post #20.

 

... but, again, they did it on the C64 first.

You can't complain about that when you've not been chipping in with concrete examples of your own theories!