NRV

July 2, 2019

If you need help with some of the rules there is always the StrategyWiki:

https://strategywiki.org/wiki/Arkanoid/Getting_Started

There was an old utility to edit the levels inside the arcade roms, don't know if this is the one that you used:

http://www.ionpool.net/arcade/arkedit/arkedit.html

I don't know if the probability for every type of capsule is documented somewhere.. well, in the source

For my own clone I assigned this values:

E (enlarge, expand) 50/256
D (disrupt.. multi ball, x3) 40/256
P (extra player) 4/256
C (capture ball, catch) 51/256
S (slow ball) 31/256
B (next board, break) 2/256

These should add to 256, but I don't have the Laser, and have another type of powerups.

Some other rules that I implemented, looking at the behaviors in Arkanoid:

- don't throw the same bonus when that power is still active (E,C,S,L, maybe D)
- don't throw the same bonus two times in a row
- there is a small possibility that a marked brick doesn't throw a capsule (I used 16/256)
- if we are moving at min speed don't give the "slow" bonus
- allow only one extra player bonus per level

January 5, 2019

Hi Pete,

...

I absolutely can not understand that you called this music Top Notch.

But, but... it was BlueMoon_001 that called the music top notch... is not like they are.. the same person..

They just have the same tastes, write the same way and dislike people that "nitpick". Perfectly normal if you ask me.

December 20, 2018

?varX = 0

.rept nosprites

:4 .byte >(sprites+14*#*4+?varX*14*4*4)

?varX++

.endr

Don't remember about nested repts, but something like this should work..

Working example from some code:

?cy = 0

.rept ITEM_MATRIX_SIZEY

:ITEM_MATRIX_SIZEX .byte <[screenBuffer1+LINE_SIZE+1+[?cy*3*LINE_SIZE+3*#]]

?cy++

.endr

I believe nested repts were added in the last few years, but you should test it.

September 26, 2018

So....

- Anybody has path data from arcade, or idea how to get it ?

- What's your source control choice - hg or git ?

- José can do gfx in a day imho

My vote goes to setting up public repo for shared code. Different gfx versions can be worked on in same time etc...

ps. Same time means like months and years between commits, but that time frame is kinda standard imho

I haven't used git much, but I still would vote for it, instead of hg.

I think probably is going to be easier to plot the trajectories taking screenshots in Mame

Never saw the NES version but thats quite close to the arcade? Why are the sounds so close, too?

Aaaargh.. you made me look for the sounds and I drifted far away x)

If you want to take a "look" at the Nes sounds:

https://www.sounds-resource.com/nes/galagademonsofdeath/sound/4033/

Or prefer a version for the 2600: (there is source down the page)

http://atariage.com/forums/topic/214498-galaga-2600-sound-test/

And this app for the Ipad is really nice:

https://itunes.apple.com/us/app/korg-gadget/id791077159?mt=8

It seems Namco made available there, the sounds of lots of old arcade games.. including Galaga, Xevious, PacMan, etc.

The nice thing is that it models a Waveform Sound Generator, like the sound chip in the old Namco arcade games,

so you can see how the sounds were constructed, in all detail.

You can see in the video the wave table (of 32 steps) for some of the sounds.

Bonus tracks.. two translations of the same interview:

http://shmuplations.com/galaga/

https://galaga.com/en/special/int_vol1.php

And a nice site that I didn't knew about

https://retrocomputing.stackexchange.com/questions/4733/how-did-z80-multiprocessing-work-in-the-namco-galaga-hardware

September 25, 2018

I forgot that I already did 10 char pre compiled sprites, of a similar size, in my recent demo.. duh.

With just preshifted sprites I did like 7 or 8 in one frame, and with a bitmap mode I think I would get better or similar results (for sprites of that size).

So doing 8 software pre shifted sprites (plus logic) doesn't sound that crazy in G15 (NTSC, 60fps).

Don't know if the test_big in this thread is going at 60Hz? But the size of the sprites is similar at what I would like to use.

Also I think we can reduce the memory requirements, for the pre shifted data, in half.. by creating a draw routine that use the sprite data backwards.

Kind of a "free" vertical flip in hardware

you have 3 groups of thought now... so do things split off into groups and see who does best? or does everybody work together trying in all directions... try both options and then run with whatever is showing the best response.? or everyone do their own thing and getting help from everyone as they go along. So many other ports to draw ideas from. (or wholesale ripping off of ) Then come back and merge them.

I only mention this because it looks like the point has been reached where there are now some good ideas, bits and pieces.

I see this as a friendly discussion to share ideas. There are similar ones from time to time.

Probably many of the people that could cooperate already have projects going on, or just don't have the time.

So I wouldn't expect a coordinate effort, but I can be wrong

At least I know that I would like to finish the sprite sheet for G15 (4 colors) and do the display routines, if someone

provides me with the arcade movement data

Go for Antic D (in spite of an uncongenial person advocates that) and use the GBA sprites as a base, so that you get these

Galaga.png

if you reduce the color count to 4...

I forgot about those.. some of them could be useful, but I would change the colors to the ones I used on my gif

Wouldn't like to go to G7, but.. that would solve all the speed and memory problems.

At the expense of worse graphics and coarser vertical movement.

September 25, 2018

@NRV

Thanks... now you do wolfenstein in 64k and for Galaga we need 1MB hahaha.... lovely missing VIC2 sprite hardware...

Haha.. forget it!

Wolf or something similar would go in a 1MB.

If you want content, textures, music, levels, then give me the memory .

Look at the good side.. it would run on a 64KB system

For Galaga I think you still can have a very good version in 64KB.

Use xor for sprite drawing, then you don't need masks.

Don't use pre shifting (there is no memory anyway).

The key question would be if you can create a draw routine, that could display 10 moving enemies (8?) in one frame (easier in PAL).

Maybe you could use only one pre shifted frame (4 bits rotation) and less sprite rotations..

September 25, 2018

IMO the horizontal expansion is the more important part of the game - it increases the difficulty in that you can't just camp in one spot and easily pick off whole columns at a time like in Space Invaders and Galaxian.

Another vote for the horizontal expansion.

The vertical one would be nice, but I can live without it.

The NES version looks ok without using it, I think.

Looks great ! And I support idea of keeping proportions as close to arcade as possible.

Now we just need extra fast gfx routines and rest is easy

You also need someone to finish the sprite sheet, for all the ships with 15 degree rotations:

The arcade game and the NES have it easy, because it seems they have hardware to flip any sprite horizontally and vertically.

They have double the horizontal resolution of the A8, but use one quarter of the data, so in the end they use half the memory needed for the A8 version.

Well, a lot less if you add the sprite masks (that the A8 needs for properly masked sprites).

If you go for all the sprites, that is something like 292 frames of 32 bytes (assuming 8x16 pixels, G15), so 9344 bytes.

If you want pre shifted sprites that means adding 14016 x 3, for a total of 51392 bytes (just the ships).

Then you need to add the masks (or just use xor or replace, to draw the sprites).

A version for 64K probably would need to use less rotation frames and no pre shifting.

A version for 128K could use pre shifting, but would need less rotation frames also.

A deluxe version, with pre compiled sprites and everything would go in a 1MB cart

Well, at least when you have the data in G15 mode, generating different draw methods is pretty easy.

I always wanted to do a demo with just the challenging stages. Would be enough as a proof of concept.

So if someone with Z80 knowledge can look at the available source (that have some comments from what I remember), and

locates the data for the movement patterns, that would be nice x)

Another way to get that data could be to look at the Mame driver for Galaga.

Locate the hardware registers that control the sprite position and "orientation" data, and add some code to log

the data written to those registers every frame.

Or go for the Space Harrier way..

September 24, 2018

I'm just a graphics guy that recently (a week ago) learned to hack them into games !!

So it's beyond my capabilities I'm afraid..

And by the way, no to the above

One Joe from Panama?

More now that you can have your own levels..

September 24, 2018

A new proposal.. well mostly what I would do if I had all the time in the world x).

Trying to go for the arcade real proportions, using software sprites in G15, narrow field, and starting by using only 4 colors:

Using 4 colors to display all the graphics in the game works pretty good, because that seems to be a limit of the hardware (4 colors per sprite).

Later, with the game already running, you could decide what to do with all the player/missiles.

Like use them for the layer of stars, the hud, the player's ship, to add color to some enemies (like the top ones), for the tractor beam, etc.

You probably could add colors via DLI's to the stars, without the need to use WSYNC, so that would be pretty cheap in processing time.

The normal arcade screen has a resolution of 224x288 pixels, and you need at least 236 scan lines to display the top enemies and the player's ship.

That's a number the A8 could display in theory, with overscan (in normal mode Altirra can show 224 scan lines).

Been this a graphics mode, you could use some display list tricks, like "compressing" the screen by removing some evenly spaced lines

(by skipping them in the display list, adding LMS instructions to jump over them).

Then you could offer the player some configurations like "full" screen, removing 8 lines, removing 16 lines, etc.

And you wouldn't need to change your sprite code, it would be totally transparent (memory would still be continuous).

Another option to remove a line could be alternating it with the next line, every other frame.

Kind of a compressed interlacing, also just by updating the display list.

You could also offer quality vs speed options to display the sprites, like properly masked, using xor, or just plain byte replace.

With more memory (or a cart version), you could go for precompiled sprites.

In X you have half the resolution, with 112 G15 pixels, so narrow field is good enough.

You have 8 extra pixels per side, that I used here to show the level "medals" and the number of lives, as an example

(with a dark grey background, that could be done with a couple of missiles).

This could complicate side clipping, but that's a problem for another time x).

Why using the arcade resolution? .. mostly to use the original movement patterns and logic.

Also, no home version seemed to have used it, so the A8 conversion would be something special.

Well Namco already did the work to convert the arcade code (three Z80 processors) to 6502, with the NES version.

They adapted the game for a normal home TV display (from the vertical arcade orientation), adjusting the moving patterns,

shortening the tractor beam, moving the player's ship 40 scan lines up, and removing the vertical "expansion" in the resting

enemies at the top. Still, the game feels pretty similar to the original.

We could use those patterns (and maybe the logic code). But, I would prefer to port the arcade version

September 11, 2018

I just hate it when I have trouble grasping a simple concept like that.

And.. who told you this one is "simple"?

I mean, I was part of a team doing a comercial Arkanoid-like game once and the "physics" for that (well, mostly collision detection and reactions) were easier, because you can search for known equations and algorithms, and you can use a good math library.

But doing something similar in a 6502 with limited memory is a lot more difficult, because you normally start from zero, and need to get very creative with the limited resources.

It doesn't make me feel too good... and I'm very critical of myself anyway, so... It scares me when I have trouble learning something.

I would say that is the real problem here, but now that you know you can start working on that

Probably nobody here wants you to do this in a fixed frame of time, so take the time you need and have fun.

And ask for help when you need it

The first possibility would be to actually keep the ball coordinates in 320P (which would be possible because the screen is actually only 128 pixels wide)and then converting them down for display.

The other one would be to keep the coordinates in 160P as they are now, convert the speeds to 320P before each direction change involving angles and then converting them back.

Working with coordinates in one byte is easier than working with two, but in the end it will depend on how many times you need to convert from one "side" to the other.

What are you going to prioritize, memory or processing time..

Are you also going to use sub pixel precision (more bytes) for the positions and speeds?

Inclusive if you choose one option now, you may want to change it later, but I would vote for one byte positions for now (for the "integer" part at least).

September 11, 2018

From the things I have done with trajectories and different angles, I always assume that the pixel ratio is 2:1.

Sure, is not going to look perfect in NTSC or PAL (probably no one would notice), but then there are optimizations

you can do with angles and speed tables, where changing an X component to Y just means multiplying by 2 or dividing by 2.

August 31, 2018

This is an "old" experiment to use char based software sprites, with source included.

Plus a nice intro using pcm 4+4 samples, with the screen on (the only reason for this to use a 1MB cartridge).

Many thanks to MrFish for improving the original graphics, adding color to the level, and creating that nice car

Features:

- 10 cars with logic to check collisions and move through the maze, every car with a different speed and acceleration.

- char based, pre shifted and pre compiled software sprites (with sizes that changes between 2x3, 3x2 and 2x2 chars).

- full copy of the background and proper masking for every sprite.

- NTSC, 60 fps, with free time to do 1 or 2 more cars probably (more in PAL).

- double buffered screen (40x25, antic4 graphic mode) and font.

- some DLI's used through the screen, to add extra color (no interleaved fonts).

I did a second version of this, but without using pre compiled sprites.

Reading the data from tables I could display 7 cars in more or less the same time (not bad I suppose).

But after my experiments with software sprites years ago, I was a little disappointed with the results that I got.

I mean, using software sprites in a bitmap mode is a lot simpler and probably faster in some cases, than using the same resolution in a char mode.

For example, if you have many small sprites (let's say 4x2 pixels) in char mode, you are going to need to touch (copy) a lot more memory,

than using those same sprites in graphic mode (in average).

And in general you are going to move more memory in a char mode, for sprites of the same (small - medium) size.

The good thing with using chars is that you can get an extra color, or do some visual tricks just plotting chars, or maybe

do font animations without touching the screen data.

And restoring the screen ("erasing" the sprites), should be faster than in a graphic mode.

Probably with bigger sprites, using chars is a win-win.

Pre shifted and pre compiled sprites use a lot of memory by definition.

In this case the car has 28 frames (4 going right, 4 going left, 4 diagonals, 8 going up, 8 going down), that amounts to something below 12KB.

I probably could reduce that number to something below 9KB, by optimizing the size of the 16 frames for the vertical movement, that also

include the empty space at the start and end of the car (to pad to the height of 3 chars).

I did it like that just because it was faster and easier to implement.

The pre-shifted frames are also used to have the tires animation, so they have more reason to exist.

rdemo_carts.zip

rdemo_source.zip

August 24, 2018

If you dont want to use math, use images!

Take a look at this:

https://gamedev.stackexchange.com/questions/43705/2d-collision-detection-for-pinball-game/43719

That link also points to this demo/game:

http://www.pouet.net/prod.php?which=24499

That has a video.. (physics seems pretty good)

And the full source code is available (6502).

It has some equations with sin and cos, but they seem to be only precalculated tables.

The amount of memory needed could be a problem with this technique, but maybe it could work well with lower res maps.

June 25, 2018

Is there a cartridge boot bypass built into your player?

After trying your demo on my 800XL with an Atarimax 8mbit cartridge I had to use the 'hot swap' technique to reflash it.

I think used to use QMEG's monitor to disable the cartridge and reboot (to boot the flasher ATR) but the hot swap worked on the first try.

Not that I know

I'm not sure what a cartridge boot bypass is in this case..

June 24, 2018

I did some experiments with the screen "on", sometime ago, and this is one of them.

Music was provided by Rybags, from the RoadBlasters arcade game (who has a Yamaha chip and a Pokey ).

roadb.zip

Source and 1MB carts provided.. (NTSC and PAL).

At some point I was going for this:

But I don't have the cpu time to activate the players for now.

That would need another round of optimization and a little of luck

The code can play different tracks, in a sequence set in a table, so maybe it can be useful for someone.

Colors are done using a table indexed by VCOUNT.

Animation is done completely by Antic

Samples played using PCM4+4, at 8 bit depth, and 15720 Hz (one sample per scan line).

June 22, 2018

After that post, Extra mode was added, and that is more like a "tower" with 2 levels per "floor"

In Extra mode you start in level A1 and have 2 options (left - right) in every level:

A1 -> B1/B2 -> C1/C2 -> D1/D2 ...

The previous modes (easy, casual, arcade) still have the "tree" structure:

1A -> 2A/2B

2A -> 3A/3B

2B -> 3B/3C

...

June 9, 2018

Thanks!

It works perfectly for the temporary label:

?GLOBAL_LABEL = 1

	org $1000
	
	.macro M_test1
?GLOBAL_LABEL = 2
.def :?GLOBAL_LABEL = 3

	.print ?GLOBAL_LABEL
	.print :?GLOBAL_LABEL

	lda #0
	
	.endm
	
	
	M_test1

June 9, 2018

Is it possible to change the value of a global label (temporary or not) from inside a macro?

When I try to do things like:

?GLOBAL_LABEL = 1

GLOBAL_LABEL2 = 10

	org $1000
	
	.macro M_test1
?GLOBAL_LABEL = 2
//:?GLOBAL_LABEL = 3

	.print ?GLOBAL_LABEL
	.print :?GLOBAL_LABEL

GLOBAL_LABEL2 set 20
//:GLOBAL_LABEL2 set 30

	.print GLOBAL_LABEL2
	.print :GLOBAL_LABEL2
	
	lda #0
	
	.endm
	
	
	M_test1

The ?GLOBAL_LABEL and GLOBAL_LABEL2 inside the macro are just different labels.

And the commented lines both throw different errors..

June 3, 2018

Two things to look at:

- The order of the updates is important, what goes first, the player update or the moving platform update (and the camera update).

- The camera has its own speed and acceleration (well, the speed depends on the distance to the player and there is a min and max speeds).

Is possible that the jitter comes from the constant "catch up" from the camera to the player's position.

Try playing with the speed of the moving platform, or maybe changing the camera logic when the player is on a moving platform.

June 2, 2018

Nice!

I played the .xex a little, would look at the code later

The platform movement is better, don't know yet why the first and last chars have that small jitter.

The laser animation slowdown seems to be just a visual thing. You kind of get the same effect when walking left or right.

Probably adding more animation frames to the lasers will solve it.

Walking over a moving platform seems a little weird sometimes, maybe when doing small movements. Kind of like the player movement cannot keep up with the platform movement.

The ladder "attach" point seems perfect now.

Regards.

May 27, 2018

mmlv6_pal_rh sounds pretty impressive on real hardware: just tested it on the 1088XEL using my Ultimate Cart. I'll try to record it through the capture dongle if I get time, since the camera hasn't really been doing these things justice. Background noise is pretty low.

Any chance of some raw stereo files for the IDE player or some code samples? I doubt I can do better than 44KHz per channel, so stereo on the IDE player may require the bitrate to be chopped in half on each channel.

My examples are for 15.7 KHz approx. and 8 bit depth, don't know if that works for you?

That's one sample per scanline, using wsync.

I also interleaved the data, first a 4K block for the left channel and then a 4K block for the right channel, for every cart bank.

I would clean the code and put it here later.

Edit: here is the source:

clean.zip

Would you say that there is more noise than what we get in Altirra?

Hello guys

How do I load a file into Altirra? I'm running a bottled version on my iMac.

Sincerely

Mathy

I don't have any experience with the mac version, but I assume that drag and drop or "Attach cartridge.." don't work?

Here are my last examples in .car format:

Atari.zip

(the _rh versions, ntsc and pal)

May 27, 2018

Yes, in the case of my examples first you need to mount the bin in Altirra as a cart type "42*: MaxFlash 1M .. (bank 127)".

After that you go to "Save Firmware / Save Cartridge" and save it as a ".car" file.

You can also mount my examples in Altirra as type "*MaxFlash 1M .. (bank 0)", but then you cannot save them as a ".car" later.

May 27, 2018

Those wonderful moments where you are finishing your code and try a final improvement, that just move your critical path code over the 105 cycles per line.

Then you cannot live with the imperfection.. so you end moving all the code to page 0 just for 6 extra cycles.

First, the pal version of the previous file, that I forgot:

stereo.zip

Then a new sample (from Marble Madness arcade), that clearly shows the stereo effect.

Check the ntsc version in the emulator if you can, the wave visualization is nice

stereo2.zip

I tried to have the smaller delay between changing the left and right channels, but I really don't know if that delay could produce some kind of audio artifact or not.