brpocock

January 26, 2008

What happened to this game? Did it get finished?

Sorry, I haven't been lurking on here often and only just noticed your comment.

Yes, Skyline was released 21 October, 2007, with a simple set of levels that nobody much seems to have liked :'(

There were also a number of critical bugs including handling of "bullets" from items used, occassional rolling of the screen due to the script interpreter running amock and taking too long to complete scripts, and I've personally been able to hang (or toss into an unplayably weird mode) the game a few times due to what I believe to be timing issues.

So, the new version under development (there are downloads on the web site of Skyline 1.1 "alpha" release already, but it's basically just a test harness as yet) is being planned for a March'ish release. I've totally scrapped the game scripts and maps and am starting over with something a bit more "game:ish" than the walk-through from October.

Unlike the "1.0" release party (in which I notably crashed the game on a 30-foot movie screen causing an ear-piercing wail until some wise soul unplugged the Atari), I'm not setting any hard dates on this release, largely because I am hoping to have some career-related news in February which may seriously impact my ability to make the March deadline. (Said news would involve relocation.)

At some point, I intend to publish the bug tracker and Subversion repository for the game source code on the web site, but at this point, Skyline is very much a back-burner project that I throw some "spare" time at from time to time, and not something I'm working on daily.

If you're interested at all in the ongoing status of Skyline 1.1, check out my blog on here or keep an eye on the web site, as I do upload binaries there somewhat frequently (although they're not much to write home about, at this point).

January 26, 2008

101011110101010110101010101110101010101010101010001010100101111010101.

I'm so tempted to disassemble that... Must.. use... time.. productively...

Must be a data table. O:-)

LB = $B

.ORG $0

0000 AF 55 AA .BYTE $AF,$55,$AA

0003 BA AA AA .BYTE $BA,$AA,$AA

0006 2A 5E C5 .BYTE $2A,$5E,$C5

000B LB = * + 2

0009 90 .BYTE $90

September 27, 2007

http://product.half.ebay.com/The-Legend-of...foQQprZ43856345

September 11, 2007

Here's a useless attempt. 40 cycles, 25 bytes.

OK, already better than my attempts. I'm still mystified, where do you even get the ideas for these shortcuts?

September 11, 2007

In the interests of getting it to Just Work At All, I'm dropping this logic actually, but thanks to you both for many useful suggestions.

My revised idea, rethinking a few things based on Thomas's comments on my blog, is to simplify the drawing list somewhat by only drawing a full sprite or not drawing it at all, which terribly simplifies the logic in the judgement routine, and the revised mess follows.

An ideal divide by seven would make the judgement code more accurate, but I'm being pessimistic and doing a divide by eight, and possibly ruling out some slots which otherwise could have held sprites, in favour of more reasonable execution times, and the fact that my local time is 3:30am and complex math is never my strong suit to begin with.

I suppose I could resort to a div7 table, as well :-( I think the valid range is only 0..49 or so, depending on how my RESPx hits end up aligning in the kernel, so at least it's a smallish table. Even smallish tables are starting to hurt me, though.

I'll dump some things to my blog in a moment, rather than polluting this abortive thread.

September 11, 2007

This is actually for the "judgement" code to decide sprite drawing-lists ... I have the amount of displacement between two sprites to be entered into the drawing list, and am judging the number of scanlines required to perform the move. Incidentally, this is including a RESPx "shortcut" that allows bumping the position effectively up to 48 clocks (see my blog for details).

I'm tinkering with pretending to move 8 clocks and then throwing in an extra count, which could taint the results, but it's just to decide the best slot in the list for a sprite, so I'm wondering if an approximation might work.

The actual motion code works out something like the above; I (sometimes) hit RESPx (at one of two fixed positions) and then whack HMOVE until I think the sprite is where I want it.

The judgement code rewrite has invalidated the sprite drawing in the kernel loop at the moment, so until I refactor that to match, this is all gut instinct.

September 11, 2007

Simple thing that's killing me.

Any suggestions for a fast "divide by seven" routine?

HMPx/HMOVE whacks give either 7 or 8 clocks of motion. Divide by 8 is easy - bit shift - but division by seven is killing me. I can live with doing a dex / sbc loop, but that isn't nice.

Math and I are not friends.

September 11, 2007

I'm just pinging this topic in case anybody knows. :-( I never did find an answer.

September 11, 2007

If you don't need to be compatible with other bankswitching methods and boards, a 16V8 could easily support a cartridge up to 256Kbytes, and a 22V10 up to 1,024Kbytes. A board using two off-the-shelf chips plus the EPROM could likewise go up to 1,024kbytes.

Realistically, full-out bankswitching is probably fine for something of the 32k/64k scale, but I'd want a little more power for anything much larger than this project.

An ideal layout for something like this (Skyline/CiE/Ursine Core) would probably include something like:

2k ROM (bankable)
1k ROM (bankable)
256B RAM as128B read + 128B write, (bankable)
64B FIFO stacks
64B FILO stacks
64B + 64B of stack retrieval registers for the above two
256B flash RAM (bankable) -- for saved game slots -- bank in persistant data, e.g. have page 0 be a catalogue/index and pages 1..n be individual players' save game slots
256B ROM at the tail for bank switching and reset vectors

Of course, that would require some major fancy logic stuff, especially if the flash could be treated as RAM ... *shrug* But that's dreaming. I seem to think you had a super cartridge logic that could do things like this designed once, about 9-12 months ago? ...

The 2k ROM could hold e.g. drawing code; the 1k ROM area the maps and graphics; the R/W RAM useful for various things, of course; the lists used for e.g. drawing lists and even preparing an entire screen's bitmap data and pulling it back down on the fly, which would be a godsend; the save game slots being mappable as RAM would make keeping persistent data a cinch; and the final ROM area would be unbanked since it mostly holds the cold start vector and some "jump to subroutine in bank x" code.

Incidentally, having a caller stack in the FILO stacks would make adapting a C-type compiler much simpler ...

September 10, 2007

I'm working with 32k for the October version, mostly because that's the largest cart parts I can get prefab from the AtariAge store. If anybody has a 64k board and EPROM for sale, I still have time to expand the ROM budget. There may be a 1.1 release following the debut with some additional (game logic only, hopefully) enhancements, since I am more or less rushing this into production no-holds-barred.

You just need to get the 64k logic for the PLD. I'm pretty sure AA has the hex for that kickin' around from back when HSR-RPG was forcasted to be 64k before it got canceled. I'd talk to Al if I was you to find out.

ALSO: I can get you the larger 64k eproms for the same price as the 32k ones if you need. $50 bucks for 50 chips, shipping included.

I actually found my Krocodile Kart, I might try a 64k test on it. I only have the 32k cart setup now (socketed EPROM) for testing.

Al had once confirmed the possibility of making 64k carts. It's quite possible. But I definitely want something to show on the 30th anniversary and so forth, so it may be a de luxe edition that goes to cartridge production as 64k or something.

I'm not brave enough around soldering irons for small work to try self-manufacture. As originally intended for CiE, Skyline will be available for AtariAge to carry if Al will do so ...

September 10, 2007

I'm working with 32k for the October version, mostly because that's the largest cart parts I can get prefab from the AtariAge store. If anybody has a 64k board and EPROM for sale, I still have time to expand the ROM budget. There may be a 1.1 release following the debut with some additional (game logic only, hopefully) enhancements, since I am more or less rushing this into production no-holds-barred.

September 10, 2007

The current format for Little Dipper project, title "Skyline," is much closer to The Legend of Zelda (original TLoZ for NES, and the SNES and Game Boy/GBC/GBA variations) than to Ultima or Final Fantasy; i.e. action RPG rather than menu-driven. No specific combat mode, just walk around and use items in the game world in real time.

FWIW.

If Big Dipper/CiE gets back into gear, the menu-based combat stuff -- some of which I think could be pretty cool -- will come back into play.

September 7, 2007

still getting my ass kicked by kernel timings, but who isn't?

One way or the other this will be released 21 October. Playable alpha release due later this month -- beta around first of October -- not guaranteeing bug free by the anniversary but close.

Club Sappho's at Metro nightclub -- where The Loft used to be -- 8pm to closing (2am) -- I'll have it on the 2600 (four switch model) hardware.

I got a tweak from general manager that we might get moved to Club Shadows, but that would mean getting a 30' movie projector to play on, so yay. Depends on some stuff happening to Sunday nights' schedules.

Hope to see you there.

p.s. development crap in my blog incl. August pre-alpha test kernel demonstrating tile draw functionality

p.p.s. Real Artists Ship. (-Steve Jobs)

August 17, 2007

Blogged some stuff. Release on track -- give or take.

July 6, 2007

ps -- aim BruceRobertP usually half-available on mobile during days if anyone having trouble reaching me -- my web colo is down since 3 July and don't yet know why, so eMail is out right now -- also, my handle here at GMail.

July 6, 2007

updated blog -- progressing -- release party 8pm on 21 October at Metro, Jacksonville, FL. New title is Skyline, and Real Artists Ship.

6 undefined symbols from machine-generated code going through ... today's bottom line sad statistic.

February 19, 2007

If you have copy of the code, posting it wouldn't hurt -- or just let me know what the date stamp on it was -- I'm still "sorting through the ashes" finding backup files to see how much was lost.

February 19, 2007

Not quite dead yet. Sorry, winter sucked for me. Recovery in progress.

July 10, 2006

To echo my blog... CiE, as such, is delayed; but the RPG engine is being used for an alternative game with the same mechanics, and CiE is still in production, just not on original schedule. Details and discussion in my blog. Thanks all.

June 21, 2006

Technically, what is the better mode to design games, c64 or c128 ? (sorry for the out of topic)

Short version? 128 mode, if you're targeting the 128, since all of the hardware is available: virtual memory mapping for multiple zero pages and stacks, dual monitors, dual CPU's, and the rest.

I'm kinda amazed that more people don't use the Z80A CPU to boost the speed of some types of operations on the 128.

June 21, 2006

16-bit chip refers
The SID, 6502, etc can only access 8-bits at a time. True, it can scan from 65,536 locations, but only 8 bits at a time.

Hence, 8-bit.

Vice versa, the SID can be adressed with 8 bits, because the CPU can only set 8 bit registers. But inside the chip, 2 of them are combined... remembering "16 Bit channels".

That's the cause for my comparision.

Well... the SID's address bus is actually 5 bits. It's just used for memory-mapped I/O. Then you have the VIC-II (C=64/128), which has a EDIT:Typo six-bit memory-mapped I/O port, but a 14-bit outbound address fetch availability.

May 31, 2006

For analog/3d... GCN controllers. The Nintendo originals are good; the MadCatz ones with soft (gel) grips are a slight improvement for some things. I particularly like the "blind" button arrangement ... A,B,X,Y are all distinct "braille'able" shapes.

For digital/2d, the Saturn controller wasn't bad, but I'd have to lean toward something more like the "figure 8" SNES control pads. A bit small for my hands, but you know, Caucasians are just too damned tall.

Actually, for modern digital/2d, the GBA or NDS layout is pretty nice, and a decent size. The SP and Micro are too small, and the GBA doesn't have a backlight, so it's not great for portables, but it's quite playable in e.g. multiplayer Final Fantasy on GCN, which is kinda surprising as it's a "2-and-a-half-D" game. (2D world but 3D view)

May 31, 2006

...what the PS2 did to Sega.

I dunno about the rest of the country, but what killed Sega around here was absolute and total lack of exposure. And (as you might guess by my presence here) I'm the kind of person who was looking for it in the shops.

I saw precisely one TV advert for the Dreamcast -- now, mind you, I don't watch a lot of TV, but I've seen far more for any other modern system. I actually saw my first Dreamcast in person yesterday at a new Rhino store in the area. I never saw one at any local GameStop, Rhino, Target, K-Mart, nor Wal-Mart (but I avoid W-M so it's possible I missed it). For that matter, I have yet to see an actual production-model Saturn in person, although I've got a PC devkit for one in a box somewhere.

I don't know who the retailers were that were supposed to be selling these Sega systems, but they didn't exactly "push" them around here.

I'm a bit reminded of the Sears/iMac debacle. The Sears in this area that got a dozen iMacs set up one in a corner with the stack of boxes beside it ... in the basement level, behind hand tools and next to tires. (These were the CRT "five fruity flavors" iMacs, so the boxes were a little bulky to carry up the escalator to the mall level.) Then Sears stopped carrying them because they weren't selling... perhaps if they had been near, say, electronics, things would have been different.

May 30, 2006

Personally I wish there wasn't a format 'war'...

I wish all manufactures made consoles of the same format which they all agree to update every 4 or 5 years. That way we can buy from the manufacturers console we can afford/ like/ better reliability or better design. But the main thing is all games work on all systems and we only need one box under the TV.

Now that's how it should be.