Jump to content
IGNORED

Java mobile games to Atari lynx games (Theory)


Europatari

Recommended Posts

9 hours ago, Turbo Laser Lynx said:

 

It sounds interesting, but  I always thought using C in a simple manner was much easier than the old basics I've tried (Basic 2 on the C64 and Basic 7 on the C128). I haven't tried any modern Basic variants, so it might be those would be easier to use. :grin: Basic v.7 was quite nice though.

 

 

 

If you want to use C, I'd encourage you to become an early user/tester of 8-Bit Unity.

 

The upcoming 0.3 release will support Lynx.

 

See this video of the product roadmap: 

 

 

And here is the Patreon site:

 

https://www.patreon.com/8bitDude

 

  • Like 2
Link to comment
Share on other sites

5 hours ago, bhall408 said:

 

If you want to use C, I'd encourage you to become an early user/tester of 8-Bit Unity.

 

I've been following that project with interest "from afar", still I have working CC65 development set ups for the Lynx, Vic-20, C64, Plus4 and very little free time to spare, so it's a hurdle moving over to something new. But who knows in the future, I'm looking to learn about developing for more and more old systems.

 

Actually there's soooo much exciting stuff going on in the retro gaming- and the retro development- world that I can't even keep up with it any more. For example there's now this development suite called Turbo Rascal too, that has already spawned a few games. "It has never been easier to program for your favorite obsolete system!" :grin:

 

https://lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/

 

 

Link to comment
Share on other sites

What about taking the Tilengine path? After all Unity is more for hi-res stuff.

 

Tilengine looks a bit like tgi_whatever engine. Just use TLN_whatever ;) 

 

https://github.com/megamarc/Tilengine

#include "Tilengine.h"

void main(void) {
    TLN_Tilemap foreground;
    int frame = 0;

    TLN_Init (400,240,1,0,20);
    TLN_SetLoadPath ("assets/sonic");
    foreground = TLN_LoadTilemap ("sonic_md_fg1.tmx", NULL);
    TLN_SetLayer (0, NULL, foreground);

    TLN_CreateWindow (NULL, 0);
    while (TLN_ProcessWindow()) {
        TLN_DrawFrame (frame);
        frame += 1;
    }

    TLN_Deinit ();
}

 

Link to comment
Share on other sites

I've been thinking that because of how the Lynx works, in many cases one wouldn't need a conventional tilemapper like on many of the other old gizmos. We'd need a program to place sprites/platforms/"tiles" on whatever pixel coordinate we'd want, that can export those coordinates. You shouldn't have to tile the background either. From what I've read here on the programmers forum (if I've understood it correctly), apparently drawing a big sprite is as fast or faster than drawing small sprites on the Lynx, so it should be possible to just scale a pixel or a small sprite for background (like I did in Reiko), or have a drawn background obviously, and then place the sprites wherever.

 

I checked with the guys on the aseprite forum, and it seems to be possible to script it to export the x and y coordinates of every layer, that way you could use aseprite as a level map program (at the same time you'd use it for the pixelart) AND you'd not be constrained to a square grid like 8x8 or 16x16 etc. (Probably many retro-people like the grid constraint for the style/look, but if you'd sometimes would want to break that constraint).

 

Quote
In Aseprite v1.2.10-beta4 1, I think that it might be possible to write down the layer coordinates using a script 1 and printing the cel position 1 in an external file. You could use --script argument 1 to run the script from the command line. If you cannot do it, I could prepare a script for you.

 

A similar x and y export could most probably be done with gimp somehow too, but at least personally I've found aseprite so much easier to work with for pixel art.

 

Quote

The 8-bit Unity has been in the works for a while, I'm not convinced it will be ready any time soon.

Yeah, at the moment TurboRascal seems to move forward much faster. Both are fabulous and interesting projects though! :love:

 

Edited by Turbo Laser Lynx
Link to comment
Share on other sites

I think, one reason for a tile based game engine is that you can save memory for the sprites and build large maps with minimum space. Like with Lego bricks. You only need a limited set and can create a Death Star or a Pony farm ?

 

I just checked out Spindizzy (any old fart here remembering this game?) and read they did need only 11KB for the large map.

Link to comment
Share on other sites

40 minutes ago, enthusi said:

And I for one seriously hope that people well also get into hardware details and value what the Lynx CAN do and not how anything can be done with the least effort possible.

I understand your point, but without a good knowledge of at least C language and old school gfx coding techniques, the learning curve for coding on lynx can be demotivating for new generations.

 

A simple language with prefactored "Bricks" to build up a game can attract new people, that with time could want to learn more and try to code in C end maybe in ASM.

 

I gave a fast look at bBasic, it has pre defined objects (not in the OOP meaning) for making basic things like displaying lives, score, sprites, etc. with only some parameter available to customize the game look. Something like the very first RADs for windows (that I hate ?).

 

Porting bBasic is not a good idea IMHO because too 2600 oriented, but taking a simple and open source BASIC and adding simple commands for such game primitives should not be difficult.

 

I can't forget my first GFX coding on C64, using Simon's Basic ?

  • Like 1
Link to comment
Share on other sites

49 minutes ago, 42bs said:

I think, one reason for a tile based game engine is that you can save memory for the sprites and build large maps with minimum space.

 

Yeah, I didn't communicate that in my earlier post, but my reasoning was that you'd indeed use it for "tiles", but you could place them anywhere and you could potentially use even less space but in a more free manner.

 

1 hour ago, enthusi said:

And I for one seriously hope that people well also get into hardware details and value what the Lynx CAN do and not how anything can be done with the least effort possible. 

 

I really do admire games that push the limits of a system, and it's so much fun to see what's been achieved, but I still think it can swing both ways. I've seen artsy dudes create amazing games, that probably wouldn't have existed at all if they'd have to learn assemby and intricate details of a computer/console at first. I think AGD on the ZX Spectrum would be a good example, I've seen so many fun games made with it.

 

I'm not by any stretch of the imagination saying that you should only choose the path of least resistance, it always pays off to study the hardware details more, and it's fun to learn new things. I just wanted to put forward (again) that I think that several approaches are valid. :D Conversely it's easy to see that engineer-/programmer-only made games would benefit from reading up a bit on for example graphic design principles. :grin:

 

Obviously it's easy to draw the conclusion that games made in collaboration between people with different skillsets are more likely to be good. But it's not always so easy to mix all the different spices into a perfect dish. it's so much fun trying to learn and do everything yourself too. ?

 

Quote

I can't forget my first GFX coding on C64, using Simon's Basic ?

I've checked it up earlier and Simon's Basic seems to have functionality equal to some of the better Basic's of the time. I had a C128 as a kid, that had the nice Basic V.7 with commands for graphics, music and even a built in sprite editor etc.

 

Edited by Turbo Laser Lynx
Link to comment
Share on other sites

I was writing something but Turbo Laser was faster and just read in my mind. So +1 on what he said :)

 

As far as I'm concerned, I'm amazed by people who master the hardware but strangely enough, I have never been passionated with ASM myself. What I like is to create games, with cool ideas, nice gameplay, depth and fun, and I feel that the extra time needed to get that entirely with ASM is not worth the price. But I admire those who take this path!

 

Ohh well this is probably why I ended up as a gameplay programmer and not an engine one :)

 

ps: on a side note, it's kind of ironic but C++ is becoming even more complex than ASM nowaday ^^

 

 

Edited by LordKraken
  • Like 4
Link to comment
Share on other sites

10 minutes ago, 42bs said:

ASM complex? Come on! It is the easiest language of all. And straight forward.

ASM is not complex. Managing directly the HW without an abstraction layer could be: you need to know very well the architecture of every machine you want to code for, while with C you can save time when there are libs like TGI or Chipper.

 

On the other hand reading code written in ASM from someone else (or your code after some years) can be challenging (it's reverse engineering, and is a difficult skill to master).

Link to comment
Share on other sites

4 minutes ago, LordKraken said:

That's one perspective ;)

 

Or maybe I could reformulate it that way: It's not complex per say, but it's less natural for the human brain/logic, and it's also harder to read/vizualize.

I can accept this argument. ;-)

	lwz	r10,MSG_PLID(r3)	// r10:= pool-id
	rlwinm	r9,r10,10,23,29		// r9:= module_idx * 4
	rlwinm	r10,r10,2,22,29		// 10:= pool_idx *4

Rotate-Left-Word-INsert-Mask - Hard to memorize how it works.

 

Link to comment
Share on other sites

3 hours ago, LordKraken said:

ps: on a side note, it's kind of ironic but C++ is becoming even more complex than ASM nowaday ^^

C++ is a train wreck since C++11. Make a small error in some virtual template library class and get 20+ pages of cryptic nonsense describing that none of your code can be compiled anymore because you screwed up by making a small typo somewhere. You can write elegant abstract code that is virtually incomprehensible. At the last step you then introduce the element "a cat" that defines what the code is all about and suddenly all the virtual template functions makes sense (to the computer - not the guy trying to understand what is going on).

Here is an "elegant" definition of a Vector in C++:

template<typename T> class Vector 
{
private:
    T *elem; 
    int sz;
public:
    Vector(int s) : elem{new T[s]}, sz{s} // constructor
    {
        for (int i = 0; i != s; ++1) elem[i] = 0;
    }
    ~Vector() { delete [] elem; } // destructor

    T& operator[] (int i) { return elem[i]; }
    int size() const { return sz; }
};

void fct(int n) 
{
    Vector<double> v(n); // acquire and initialize
    // .. use v ..
    Vector<int> v2(n)
    // .. use v2 ..

} // v2 and v destroyed

Or in ASM:

.byte 1,2,3,4,5,6,7

Which one is easier to read?

Link to comment
Share on other sites

4 minutes ago, LordKraken said:

that's a biased presentation I would say...

 

this is how i sort my vector:

std::sort(myVector, someComparisonLambdaOnOneLine));

 

how do you do that in asm ;)

It depends all on the right libraries/macros:

 

MOVEI myVector, ptr

MOVEI compareRoutine, cmpPtr

lda #vectorSize

jsr quickSort


 

 

  • Like 1
Link to comment
Share on other sites

I was merely commenting on the evolution. These days few people that start with BASIC end with Assembler or even C. I have seen many great C games, last but not least in this particular year and Wyvern Tales is currently among the very best of this age, too.

To truly keep a system alive and going you (also) need a certain amount of people that are willing to dig deep and code bare metal in the long run, in my experience.

  • Like 2
Link to comment
Share on other sites

Some nice language with a modern syntax would be a good thing for the Lynx. I was looking at Python but that is a bit overkill for a small Lynx.

 

One interactive language that could fit the bill is Red. It has a built in compiler and you could extend the language a little like in Forth. But it has an understandable syntax.

if a < 0 [print "a is negative"]

c: 5
while [c > 0][
   prin "o"
   c: c - 1
]
; will output:
ooooo

And functions:
 

twice: function [a [integer!] /one return: [integer!]][
        c: 2
        a: a * c
        either one [a + 1][a]
]
b: 3
print twice b   ; will output 6.

This would compile to very compact code that fits in eeprom. So it would be possible to write code on the Lynx.

Link to comment
Share on other sites

I think there is nothing wrong with C. I saw once the code from a commercial (IAR Systems) compiler and the it was great.

The problem of cc65 is the 16bit approach. Back then with newcc645 I spent a lot of time to improve the optimizer and ended up to write compiler friendly code. Which is, in the end, no longer readable. So C lost its point.

Link to comment
Share on other sites

Not saying c is bad. I use it at work alot. Neither is cc65 in some ways but one should know what is happening. Here is a small c code, followed by plain cc65 output and a small manual routine. For the given task the C version is certainly fast enough still but you see at once what the costs of generic code are.

https://pastebin.com/UN6UQaVY

  • Like 1
Link to comment
Share on other sites

I must agree that to date the best approach for single routines is structural asm. Like BLL.

 

The problem is that there is a lot of asm primitives that you need to learn.

 

My favourite coding language would be something like Occam. Just 14 mnemonics, indents to define the blocks, IRQ's are part of the control syntax, parallell execution if the CPU supports it. And very compact code.

ALT
    msg?VBL
         PAR
             SwapBuffers
             IncrementClock
             AdvanceMusic
    msg?Timer6
        SEQ
             StreamPCM

ALT = the first channel that becomes ready
PAR = execute these things in parallell
SEQ = execute these things sequentially
? = read from a channel
! = write to a channel

 

Channel read/writes are blocking. So any code waits at the channel until the other partners execution comes there as well. Then the later arriver takes care of DMA transfer of the message in memory or out of the chip to another CPU.

 

Oh, and most important! No pointers exist. No memory allocation is possible. Only pre-defined static memory. No type casts are possible.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...