Arlasoft
-
Posts
81 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Arlasoft
-
-
Here's a list of game ideas I've had for the Channel F but not had time to make yet:
Horace Goes SkiingSnake 2 (Nokia 3310)
Bejewelled
Columns
Dr Mario
Puyo Puyo
Pyromind (PC)
Di Lithium Lift (Speccy)TNT Bomb Bomb (PC-88)
I also drew the background for Donkey Kong Jr Game & Watch but can't for the life of me find the Gimp file....
-
1
-
-
1 minute ago, e5frog said:
Christmas lights Google logo... what else?
On mine it's a Jerry Lawson tribute, with a little playable platform game editor. Slightly misleading as to what the Channel F was capable of but hey!
-
3
-
-
Just to clarify, I'm not cxsfx who created the original browser-based game. Like Thomas I saw it in a roundup for the game jam it was written for and thought it was a nice little concept.
Happy that Thomas has built on the idea, my version is very much one of those frustrating 'endless runners' like Flappy Bird that are anything but endless due to their difficulty....but like Flappy Bird it does have the 'one more go' factor.
It's pretty crazy that two of us were working on ports of the same extremely obscure game tucked away in a corner of the internet, for the same system at the same time!
-
7
-
-
I'll see if I can drum up an order in one the discord servers I'm in. By the way you have me down as USA in the original post, I'm in the UK - let me know if you need my address again!
-
1
-
-
5 minutes ago, Al_Nafuur said:
I have sent you an PM about your game. Have you seen it, or do you have your notifications disabled?
Sorry I'm currently on a cruise ship so haven't had any internet for a few days. Will reply properly when we are back!
-
1
-
-
28 minutes ago, Retrogamerrhys1 said:
Yeah, I mean source code I think? Although I have come across disassemblies from archives which seem to offer what I want, a breakdown of the program.
A raw disassembly wouldn't be much use, you can get this for any game using Stella in any case.
The ones with comments, labels, constants etc have been reversed engineered to the point where it could be considered as good as having the original source code, probably better because back in the day they didn't have the space or time to put extensive comments. So there's a big difference between 'commented disassembly' and 'disassembly'.
-
-
So is the consensus that the flickering is too much on real hardware to make two player viable? Bearing in mind even single player Puyo Puyo is normally player against an AI opponent.
I'll need to watch some videos of endless solo mode in Puyo Puyo Tetris to see how fun that might be, think there's a mode where you have two minutes to score as highly as possible too.
-
58 minutes ago, Thomas Jentzsch said:
Definitely too much flicker for me (but I am sensitive to flicker).
I think it would help a lot if you would use interleaved flicker.
I had a feeling it would be too much on a real system. Can't really insist everyone plays on Stella 😬
-
45 minutes ago, Ecernosoft said:
Sure thing!
I'll be testing first on the 7800, since the 2600 isn't set up (Since I have a 7800.)
Edit: Just tested it. Looks fine, but has "timing problems" where you're not updating the colors at the right time.
Part of the red faces (On both sides) has some purple. You're updating the colors too quickly there.
Minus that, it looks great! Keep up the good work!
Guess that's an emulation issue, i.e. timing is more forgiving. If I delay by even one cycle, the rest of the colours would be out.
-
2 minutes ago, Ecernosoft said:
I have a 7800 and a 2600, I can test for you if you want 😃
That'd be cool, thanks!
-
How it looks in Stella....
-
1
-
-
Have been noodling with some puzzle game kernels after seeing the Dr Mario example. This one might have some promise, and certainly a solo version is definitely viable, but for two players I was curious as to how this looks on real hardware.
In Stella, with phosphorus turned on and blending set quite high, it looks great. But in the Javatari emulator within 8bitworkshop the flicker is uncomfortable. Javatari seems to have some CRT options but none of them seem to make much difference at all.
I suspect a real 2600 on a CRT it will be somewhere in between?
-
1
-
-
On 10/13/2022 at 1:15 PM, Cisano said:
Bravo! It can become a great port. Only one thing.
The background using shading colors, for me, penalizes the good graphic work you are doing.
Better uniform blu sky and ground.
It's looking increasingly likely it will have to be just one colour anyway, as on scanlines where enemies are being repositioned I have no cycles available to update the BG colour, so when they move vertically the location of the bands change.
-
On 10/7/2022 at 8:40 PM, Ecernosoft said:
Hey, can you provide a .a or .txt source file? Thanks!
I'll share the source code when the game is finished.
-
Finally got sprite multiplexing working reliably, had to do all sorts of gymnastics with my kernel. One more cycle on the last row of each block and the positioning code pushes it onto an extra scanline.
Also moved the level data to a separate bank and added a second level to test progressing to the next one.
Last job before coding some enemy behaviour is to find a place to perform the kernel loop exit check without a couple of junk scanlines being drawn.
-
9
-
-
Just now, Cris1997XX said:
You could always opt for the DPC+...😂
Haha - at that stage I might as well just go back to C64 or Unity
-
On 10/2/2022 at 6:47 PM, Ecernosoft said:
72 bytes?
I used 48 bytes for ICT2600, you can go check it out in this link:
72 bytes = 26 rows with three bytes for each. Same as the arcade except rows are 6 pixels tall instead of 8.
Not much I can do about that without significantly changing the level designs, which are pretty integral to how the game plays. 24 rows might work like the single-screen stages in Mighty Bomb Jack but probably not worth it for the sake of 6 bytes, especially now I'm using Superchip RAM. -
On 10/1/2022 at 8:17 PM, Dionoid said:
Nice! The player movement feels like the Bomb Jack I used to play on my C64!
I remember the later levels can have quite a large number of enemies floating around the screen, so I think that's going to be a challenge. But maybe that can be solved by having less, but "smarter" enemy sprites.
I noticed that the vertical wall is having the same color as the bombs, which can be confusing. A technique that might help out here, is to use playfield color-switching, where you're changing the PF color on each scanline, and now the even lines are used to display the walls/platforms, while the odd lines are used to display the bombs. This way, it appears you are showing orange/red bombs and yellow platforms on the same lines, but actually you're alternating the display for each scanline like this (using a 6-scanlines repeat):
line 1: orange/red (display bomb)
line 2: yellow (display platform / wall)
line 3: orange/red (display bomb)
line 4: yellow (display platform / wall)
line 5: orange/red (display bomb)
line 6: yellow (display platform / wall)
I’m not sure if displaying PF on each scanline fits your kernel, though.
Anyway, great start to this game!Yeah, unfortunately there's no way I can afford to be drawing the playfield on odd rows as well. That scanline is going to be for A) drawing the current enemy, B) getting sprite and colour pointers for the next enemy or C) positioning the next enemy. With an asymmetric playfield I need to be setting PF2 on exactly cycle 48, as well as clearing PF1 before that, so that would come slap bang in the middle of the enemy code.
-
Have done some shuffling around to free up cycles for enemy sprites, so now the entire playfield, background colour, player sprite & colour are done in one scanline, leaving this kernel to repeat 26 times:
PLAYFIELD: (lines 0,2,4)
- 11 cycles from 49-60
BLANK: (1,3)
- 76 cycles from 1-76
LAST ROW: (6)
- 62 cycles from 1-62.
My fingers are crossed that with the play area starting at PF1 and only being 96 pixels wide, there will be enough time to decide whether to reposition P1 or draw it/do nothing, and still be able to position the sprite without calling a WSYNC. Taking a break for the weekend now for Ludum Dare, which depending on the theme may well be a 2600 game.
-
1
-
New version uploaded to itch.io with a couple of bug fixes.
-
1
-
-
1 hour ago, SpiceWare said:
Looks awesome!
I suggest trying a reflected playfield and only update PF1 and PF2. It might allow you to increase your gameplay area. I used this technique in Stay Frosty when I couldn't accomplish my original goals.
Thanks, I'll take a look at the Stay Frosty stuff, especially the masking as I'm starting to implement enemies.
I'm already using just PF1 and PF2 in mirrored mode, I just don't bother with the second PF1 for the sake of two extra playfield pixels, especially as the PF data has to be stored in ZP (although I could move it to the super chip RAM) so the bombs can be cleared - 72 bytes is a hefty chunk as it is. -
Just noticed it glitches a bit in Stella, having tested in 8bitworkshop/javatari. Working on it...
EDIT: That's better!
-
1
-
-
I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible.
What I have so far:
- ability to display maps to match the arcade, albeit 24 x 26 blocks instead of 26 x 26 (first level in so far)
- map uses PF1 (left only) & PF2 to minimise cycles required
- player movement and animation including walking, jumping, gliding, and falling
- fire bombs displayed in the same order as the arcade
- bombs can be collected and score updated accordingly
- 8K ROM with 128 bytes extra RAM. Bank 0 currently un-used - title screen, music data & routines etc?
In the attached binary you can mess around on the first level, with an added vertical wall for testing. You can fall through the top of that wall but in a proper map there would be another platform stopping that happening.
For those not familiar with the game you can hold up while jumping to get extra height, fire while jumping will cancel the jump and spamming fire while falling allows you to 'glide' across the screen.
-----------------------------------------------------------------------------------
Now comes the hard part - enemies and power-ups. I'm making this post partly to gather some thoughts on the best way to handle those.
I have a pretty tight kernel using macros and 76 cycle-exact sections to avoid looping and WSYNC's, giving the following cycles free:
[PLAYFIELD, BLANK, PLAYFIELD, BLANK, PLAYFIELD, LAST ROW] repeats x 26
PLAYFIELD:- 7 cycles from 30-36
- 16 cycles from 49-64
BLANK:
- 62 cycles from 1-62
LAST ROW:
- 47 cycles from 13-59 or 5-51
PL1 is free for enemies, and I was thinking of using a ball or missile for the main power-up, as it doesn't matter if that flashes random colours based on the playfield or player colours.
Not sure about the 'B', 'E' and 'S' power-ups as having them using PL1 too just makes that even more complicated, but they do really need to be identifiable.I'm not adverse to changing enemy behaviour quite a bit to suit the 2600, keeping in them in horizontal zones rather than chasing the player all over the screen. They would still get in the way of the bombs you need. Or perhaps I have enough free cycles for genuine multiplexing....?
One of the main obstacles is that Y and X are both tied up, Y counting down scanlines until PL0 should be drawn (similar to DrawHarry in Pitfall), and X keeping track of the map row from 25 to 0.
-
10
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
the official Channel F thread!
in Classic Console Discussion
Posted · Edited by Arlasoft
Some GFX I did dig out, might provide some inspiration
Berzerk
Binary Land
Dr Mario
Jawbreaker
Minesweeper
Omelettes
Some sort of poker strategy game
Rectris
Nokia Snake
Tapper