Jump to content

NRV's Photo

NRV

Member Since 1 Nov 2006
OFFLINE Last Active Yesterday, 2:21 PM

#4191157 Secretum Labyrinth Dark Castle teaser video

Posted by NRV on Sat Jan 5, 2019 11:45 AM

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.


#4121784 Galaga for 8-bits?

Posted by NRV on Wed Sep 26, 2018 4:46 PM

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 :D
 

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-r...ath/sound/4033/

Or prefer a version for the 2600: (there is source down the page)
http://atariage.com/...600-sound-test/

And this app for the Ipad is really nice:
https://itunes.apple...d791077159?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/e...al/int_vol1.php

And a nice site that I didn't knew about :)
https://retrocomputi...galaga-hardware


#4120939 Galaga for 8-bits?

Posted by NRV on Tue Sep 25, 2018 3:34 PM

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 :D
 

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 :o) 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 :D
 

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
 
attachicon.gifGalaga.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.


#4120772 Galaga for 8-bits?

Posted by NRV on Tue Sep 25, 2018 12:44 PM

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:

galaga.png

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 :D

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..


#4119963 Moon Patrol hack !

Posted by NRV on Mon Sep 24, 2018 11:25 AM

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..
  • TIX likes this


#4119722 Galaga for 8-bits?

Posted by NRV on Mon Sep 24, 2018 1:15 AM

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:

galaga_a8.gif

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 :)


#4102611 Char based software sprites

Posted by NRV on Fri Aug 31, 2018 12:26 AM

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.



Attached File  rdemo_carts.zip   1.62MB   47 downloads

Attached File  rdemo_source.zip   870.15KB   42 downloads


#4098559 Baby Pac-Man

Posted by NRV on Fri Aug 24, 2018 3:26 PM

If you dont want to use math, use images!
Take a look at this:
https://gamedev.stac...ball-game/43719


That link also points to this demo/game:
http://www.pouet.net...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.


#4055652 PWM experiments

Posted by NRV on Sat Jun 23, 2018 9:09 PM

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 :)).

roadb4c.gif

Attached File  roadb.zip   3.93MB   91 downloads

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

At some point I was going for this:

roadb4d.gif

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 :D
Samples played using PCM4+4, at 8 bit depth, and 15720 Hz (one sample per scan line).


#4054905 Pad 1.5 beta

Posted by NRV on Fri Jun 22, 2018 5:29 PM

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
...


#4035723 Using Pulse Density Modulation for 8-bit PCM

Posted by NRV on Sun May 27, 2018 4:08 PM

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:
Attached File  clean.zip   3.39MB   47 downloads

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:

Attached File  Atari.zip   2.61MB   64 downloads

(the _rh versions, ntsc and pal)


#4035589 Using Pulse Density Modulation for 8-bit PCM

Posted by NRV on Sun May 27, 2018 1:33 PM

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.


#4035289 Using Pulse Density Modulation for 8-bit PCM

Posted by NRV on Sat May 26, 2018 11:29 PM

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:
Attached File  stereo.zip   1.11MB   42 downloads

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 :)

Attached File  stereo2.zip   3MB   48 downloads

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.


#4035190 Using Pulse Density Modulation for 8-bit PCM

Posted by NRV on Sat May 26, 2018 7:42 PM

Well, this is real stereo, but the effect is kind of subtle.
Will try a better sample later and with less noise.

Attached File  stereo.zip   1.11MB   40 downloads


#4035024 Using Pulse Density Modulation for 8-bit PCM

Posted by NRV on Sat May 26, 2018 1:53 PM

I did a quick test with the same song playing in both channels (left / right) and at least in emulation it seems alright.
So, can someone test the "_rh" versions in real hardware (1 MB carts for NTSC or PAL)?
Probably would try to do a real stereo test later (is a little more complicated, but should not be much more).
The "_emu" versions sound good in Altirra with the stereo configuration (and louder than mono).

Attached File  monox2.zip   1.69MB   44 downloads