Welcome, Guest. Please login or register.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Sdw

Pages: [1] 2 3 4
Thanks for arranging the compo, and congratz to the winners!

Code: [Select]
Dither256byte                         5
Core (demo)                           9
Kscope (demo)                         7
SIDBasic                              8
Squares 256byte                       7
Tube 256byte                          6
Snake 256byte                         7
Alien 8 (conversion)                  7
Hobbit (conversion)                   8
Wolf 2004 (conversion)                7

Here are my votes, as I stated before I thought it is hard to know how to judge some works, and also in relation to eachother. for example how to compare an original sizecode demo towards a converted game? Very hard to know how to score them, so perhaps my votes are a bit strange! :)

Enterprise DevCompo #2 / Re: Q&A
« on: 2017.May.23. 17:34:14 »
Sorry for not voting!

I saw that other contributors have voted by simply ignoring casting votes for their own entries, which seems like a good idea.

But I must say that I find it very hard to give a fair score to the conversions, as I don't quite know what to look for.
* Is it if the converted game is fun and great to play? This is important, but doesn't really come in as a factor on how good the coder is.
* Is it how much enhancements has been made from the original (in which case one needs to find that and play it to compare)?
* Is it how hard it is to do the conversions (ie. how hard it was to reverse-engineer the original code etc.) which is also very hard to determine unless you know the original code.

So that's why I didn't vote at all.

Enterprise DevCompo #2 / Bars1kb/Genesis Project (1kb intro)
« on: 2017.May.15. 22:54:02 »
Here's another small intro, this time with music and several effect-variations, a bit larger this time though, just under 1kb.

YouTube video

Aha! Thank you both, turns out things aren't as easy as I thought!

I have an LPT which triggers an IRQ on the first line of display, and then I try to have my code on the CPU stay in sync with each drawing of a rasterline on the screen. For now I have timed it by hand by simply setting the background color each line so I can visually see if I am in sync or not, and it works OK. But then I guess it's not as simple as removing that out and replacing with dummy code taking the same number of cycles, since as you say Nick-outs can stretch. Maybe the best option is to time until it looks right, and then simply replace so that the background out (0x81) is zero all the time, that way I keep the timing exactly as it is when it "looks" OK.

...and does it get affected by anything so that it isn't always the same?
I guess memory wait states could be one such thing, but assume we are running with:
Code: [Select]
ld a,0x0c ;disable
out (0xbf),a ;memory wait states

Programming / Re: Sizecoding on the Enterprise
« on: 2017.April.27. 14:03:32 »
Ah, thanks! Enabling interrupts (even if it meant that I needed to set up the stack) saved me enough on the vbl wait that I could do a proper clear of those bytes and still keep below the 128 byte limit.
So now the intro is finished and can be found in the DevCompo forum!

Enterprise DevCompo #2 / SlantRasters (128bytes)
« on: 2017.April.27. 14:01:46 »
Unfortunately it seems unlikely that I will be able to finish a reasonably complete preview of my Enterprise game in time for the DevCompo 2017, so instead I'll try to support the compo with some smaller productions.

Here's a world first (I think...) - 128 byte intro on the Enterprise 128!
Not easy to get much done, setting up the LPT takes quite a large percentage of the code.

Thanks to everyone who helped me with tips&tricks for optimizing size!

Programming / Re: Sizecoding on the Enterprise
« on: 2017.April.27. 12:07:19 »

Another question, can anything be assumed regarding memory init values? Especially the memory after the end of my program, where I use about 16 bytes that need to be zero. It works fine both in emulator and on my real EP128, but I can imagine that there are no guarantees.
My program loads from 0x0100-0x0170 (yep, I'm trying to do a 128 byte intro! :) ), but then I'm using 0x170-0x180 as well and need that to be zero, and I don't have enough bytes left to do the initialization of that.


Oh! And is there a shorter/smarter way to wait for VBL than:
Code: [Select]
in   a,(0b4h)
bit  4,a
jr   z,waitvbl

Programming / Re: Sizecoding on the Enterprise
« on: 2017.April.26. 23:26:01 »
Another question - is it necessary to initialize the stack pointer? It skipped it (saving 3 bytes) and everything seems to work fine, but I see that all other entreis has code that sets SP so I guess you should do it anyway?

Programming / Re: Sizecoding on the Enterprise
« on: 2017.April.26. 23:18:36 »
I looked into the code in the Hungarian section. If I understand correctly, the 16 bytes from the header get loaded into either 0xBF0C or 0xBF08, and by adding a relative jump + 2 nops, you can then use the 8 remaining bytes for "real" code. Neat trick!

Programming / Sizecoding on the Enterprise
« on: 2017.April.26. 21:41:50 »
There have been some really nice 256 byte entries in the devcompo (and I'm working on what might become one as well).

But what *is* 256 bytes in the EP128-world? I saw some entries that seemed to go for the strict 256 byte filesize rule, while some others seemed to ignore the 16 byte header and use 256 actual bytes, giving a 272 byte file size.

I am trying to target the strict 256 byte filesize, but thought I would be smart and try to use the 12 seemingly unused bytes in the header to have 252 bytes available instead of only 240 as I have now, but couldn't get it to work, I guess these bytes aren't loaded to memory at all.

Enterprise DevCompo #2 / Re: Squares 256byte
« on: 2017.April.25. 23:36:41 »
Cool, and even with sound included!

Enterprise DevCompo #2 / Re: Tube 256byte
« on: 2017.April.25. 23:26:32 »
Nice sizecoding effect!

I looked a bit in this source (and your other 256 byte intro) and found some really neat stuff for setting up the LPT!
I guess 0xBFF4 points to an address where the system LPT can be found, and then 0x1c0 bytes into that you get the whole, X lines of lower border, sync stuff, Y lines of upper border, right?
I think I'll need to steal that for some stuff I am working on! ;)

Thanks for the suggestions Zozosoft!

Though I think that adding an option to disable music will not make much sense. It's not like it's a separate loading music, it's the main music that will play through the entire demo.
If I were to stop calling the music player while loading, it will be out of sync totally anyway on slow loading systems when the next part starts (for example, if I want to load 10240 bytes, it will take 20 frames x 512 bytes. If I don't call the music player those 20 times while loading, it will be off by almost half a second when the next part starts).
Perhaps I could modify the music replayer to have an option to keep calling it the correct number of times while loading, but not outputting at all to the sound registers and have silence).
I don't think that would be good either, since my plan is to really have a high data flow, say 10-20 seconds of effect that can use the entire memory, then it's time to load 25-30kb of new packed code/data which will take a couple of seconds with my 512 byte/frame loader, and then the next effect and so on.
With a slow loader then it would be 10-20 seconds of effect and music, then maybe 10-20 seconds (with disk, I guess) or minutes even (with tape) with silence while the slow disk loader is loading, and then music resumes.
It would not be a good experience either way.

Perhaps something I will do it like this:

Use the probes you suggested, and then -
* If tape only or drive number 1-4 => Show warning "Demo will not work properly" - but let the viewer see it anyway, with crappy slow "music" (ie. notes that last several seconds...) while loading.
* If emu or 5/6 => Start demo as usual, no warning shown.

So for users with RAMDISK, it's up to them to copy the demo into it before starting the demo.

The truth is that I think most people will only watch the demo on YouTube, a few will use ep128emu and some real enthusiasts will use real Enterprise 128, but I think most of them will have either SD card or RAM expansion available!

Pages: [1] 2 3 4