28 November 2015, 23:34 | #21 |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
I agree. This game is shaping up nicely
|
29 November 2015, 06:53 | #22 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
My, what a bunch of cute little monsters.
This looks really nice. Is the blue background in this picture fully composed of sprites? It really does not feel that repetitive. Since you said that Fast RAM allowed you to handle more monsters I assume that by "engine" you also include gameplay code? |
29 November 2015, 10:11 | #23 |
Registered User
Join Date: Feb 2014
Location: Warszawa / Polska
Posts: 1,860
|
It looks very promising please do not abandon it. I would love to play this game one day.
|
29 November 2015, 18:50 | #24 |
Registered User
Join Date: Oct 2014
Location: Germany
Posts: 195
|
@Gzegzolka: There are no plans to cancel the project. Not yet...
@ReadOnlyCat: The "spritefield" fills the whole background, repeating itself. It is build out of 6 sprites. (96x64 pixel) The 8th sprite is not available because of the scrolling and the 7th sprite makes problems on very early agnus chips. But 6 sprites are enough, obviously... And yes, the speedtests have been done with the gameplay code. The code is designed to write the blitter registers between gameplay handling. (to enable the blitter to run concurrently) |
29 November 2015, 21:09 | #25 | |
Registered User
Join Date: Jun 2014
Location: milan / italy
Posts: 174
|
Quote:
By the way, just checked your website, I like your style and it is awesome what you are able to do with a C64. |
|
01 December 2015, 09:59 | #26 |
Registered User
Join Date: Oct 2014
Location: Germany
Posts: 195
|
@ovale: Yes, the game mechanics themselves are written in C (and they're identical for C64 and Amiga). But there's also assembler code which handles scrolling and sprite multiplexing for the C64 (lowlevel6502.s). On the Amiga, there's an additional layer (cameo64.c) which has the same API as the C64 lowlevel code. This was necessary, because my low level code on the Amiga handles "sprites" and scrolling differently than on the C64. |
01 December 2015, 13:48 | #27 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,188
|
Which C compiler do you use for the C64? Unless it's a good one (of which I'm aware of none) it might be a candidate for optimization.
|
01 December 2015, 18:06 | #28 | |
Registered User
Join Date: Jun 2014
Location: milan / italy
Posts: 174
|
Quote:
I always thought that C is the right choice for Amiga games but for C64 games, well ... thus is a surprise. I would love to see this code if you will release it some day. |
|
01 December 2015, 18:36 | #29 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
Quote:
Not only Lazycow has explained that the core of the engine runs in assembler, most C compilers will turn the C into decent assembler anyway. He's also having the game mechanics there, which is perfect, because then the game becomes perfectly portable to whatever platform! And most importantly, Lazycow is actually delivering a proper polished game to the Amiga, which is more than most people can say. It will run fine and that's all that matters. He knows what he is doing. |
|
01 December 2015, 19:24 | #30 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,188
|
I was thinking of the C64 version. The ANSI/ISO C standard assumes that an array index is type int and an int is no smaller than 16 bits. This requires expensive pointer arithmetic on a zero page register followed by an indexed indirect lookup. If C allowed 8 bit indexing, it would be another story.
|
01 December 2015, 21:13 | #31 |
Registered User
Join Date: Oct 2014
Location: Germany
Posts: 195
|
It's kind of a balance act... Assembler can be faster than C, but it needs more development time. (a valueable resource) So it might be wise to use some C, but then the game has to be simpler... yada yada yada... @Samurai_Crow: I used "cc65". The generated code can be ok, but ONLY if you follow some rules while programming. (not a trivial task) Hm... yes, cc65 can generate code to access tables with an 8bit index without a ZP pointer. @ovale: I am thinking about releasing the low level code at some point. But it has to be finished, first... uh oh... |
01 December 2015, 22:52 | #32 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
|
02 December 2015, 10:42 | #33 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,188
|
Quote:
Code:
struct thisStruct { int x; char *y; char z; }; struct thisStruct w[256]; Code:
char x_hi[256]; char x_lo[256]; char y_hi[256]; char y_lo[256]; char z[256]; int xbuf; char *ybuf; /* if possible, map ybuf to a zero page register */ register char wbuf; /* if possible, map wbuf to the y index register */ #define xget(index) wbuf=(index); xbuf.hibyte=x_hi[wbuf]; xbuf.lobyte=x_lo[wbuf]; #define yget(index) wbuf=(index); ybuf.hibyte=y_hi[wbuf]; ybuf.lobyte=y_lo[wbuf]; /*the z array can be accessed directly */ I've been meaning to make this type of code available as a shared library on the Amiga. Let me know if you are interested in publishing the code as such. |
|
26 January 2016, 21:09 | #34 |
Registered User
Join Date: Oct 2014
Location: Germany
Posts: 195
|
@Samurai_Crow: Yes, nice shot! This would probably generate the fastest and shortest code with the cc65 compiler. You can also use pointers to structs if the pointer is a register variable, which generates only slightly larger code. But there are some pitfalls you have to be aware of.
The problem with a library of the Powerglove low level code is that it would need some extra work to make it more flexible. Currently it is pretty much designed around the game with hardcoded limitations. Update: Early parallax scrolling test. Currently, it's too slow on an unaccellerated A500, but I am working on it. |
26 January 2016, 21:22 | #35 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
Looks beautiful
Last edited by Amiga1992; 14 August 2017 at 20:16. |
26 January 2016, 21:25 | #36 |
Registered User
Join Date: Jun 2014
Location: milan / italy
Posts: 174
|
Wonderful!
Do you have references to some document that explain how to obtain efficient code with cc65? |
27 January 2016, 20:37 | #37 |
Registered User
Join Date: Oct 2014
Location: Germany
Posts: 195
|
75% of the cc65 optimization tricks are explained in the ... ... (drumroll) ... cc65 manual.
(It is actually pretty good) With these hints alone you can easily double or tripple execution speed. |
31 January 2016, 17:51 | #38 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
|
17 February 2016, 15:25 | #39 |
Registered User
Join Date: Jan 2010
Location: >
Posts: 2,913
|
Wow missed this one, looking great! Looks super smooth, can't wait until the finished game!
|
17 February 2016, 20:27 | #40 |
Jackie Chan
Join Date: Mar 2012
Location: Ireland
Age: 46
Posts: 992
|
Looks good indeed. Will there be a physical release? Its all the rage right now, tanks, furry, tales of gorluth and maybe even maxwell mouse will all see physical releases.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[ongoing] DosBox AGA (v0.74) | NovaCoder | project.Amiga Game Factory | 182 | 14 January 2022 03:26 |
[Ongoing] Blob Attack II | Arne | project.Amiga Game Factory | 43 | 16 December 2020 19:21 |
[ongoing] Catagon | BSzili | project.Amiga Game Factory | 17 | 14 August 2015 19:18 |
KG's HOL problems (Ongoing) | killergorilla | HOL data problems | 102 | 24 April 2011 12:34 |
Is this still an ongoing project? | garyg | AMR suggestions and feedback | 17 | 04 October 2010 22:25 |
|
|