STGraves

I tried to cross compile it again following this guide http://www.hacklab.nl/c64-programming-on-a-android-device.htmlbut I had no success, well barely, it compiles but extremely simple programs and exclusively c64 ones, no atari VCS game that I've compiled using the cross compiled version of dasm has worked at all.

Yeah that's the problem, the reason why I want it in assembly is because I want to code on the go, on my computer no problem, because I know that there I have both the bB and asm files, but not on my phone, I want to code on the go because I don't have access to my computer all the time but I still want to be able to program wherever I am.

I saw a post on a website which involved cross compiling dasm for programming the c64 on android, I tried and it sort of worked but exclusively with c64 programs, I couldn't get any atari assembly games to run at all, and I'm curious to know if anyone knows if it can be done for atari 2600 games. Thanks in advance.

Can batari Basic code be converted to assembly?

And honestly wine is out of the question, because not even on Ubuntu is useful for compiling at all.

Yeah I actually tried xD, without much success on bB, but dasm sort of works but not quite, the reason I couldn't do it for bB is because I don't know how to cross compile it

In terms of code I know is possible, but compiling I've heard that it's possible but haven't accomplished it, to compile the game on an android smartphone.

After all this time I finally discovered that object oriented programming can be used in batari Basic xD, *facepalm* I know that is embarrassing the time it took me to find out that you can Dim anything and rename it xD, I'm currently working on a interesting game idea, maybe not so original but I think it's clever, once I have the first playable I'll upload it for anyone interested in playing it, I'm looking forward for testers .

Yeah, hahaha something funny happened last night right after I wrote this, I realized the fact that I knew how to do it xD, it's just that I was tired and I didn't thought of it til later.

I made a game in assembly using such principle following one of the many guides in randomterrain's website, but it's been a long time and I have forgotten how I did it, I would like to implement a similar idea in batari Basic, I attach both the game and the code so you can understand what I mean, the reason why I want to use the ball as an enemy and not a projectile is because I'm using both player1 and player0 to make one more detailed character, and I need a sort of enemy like the one on the assembly game that I'm attaching here, I want the game to look good and to be simple, mainly because I have 'til sunday to finish it, yeah for St Valentine's day xD. Could anyone be so kind to give me some sort of guidance on how to do so please? Thanks in advance. gametest.bin gametest.asm

I understand you, the idea is quite hard to accomplish on the VCS considering the tons of limitations that the system has, yes please, I'd love to see and understand how it works, because the game got my attention so bad that, if you'd agree, I'd love to help you with it!

Yeah, bently's family dinner, a game that I'd love to see finished, actually that one inspired me for the multicolored sprites.

I know, and actually I do know the problem, but I couldn't fix it and tried different things, but until I thought on the counters method I was stucked and that's why I was using the pfscroll.

Perhaps but bblint doesn't show me any error at all, and besides my method worked very nicely without issues, all it needs is a bit of tweaking in order to work with even more screens, with 5 it works great.

I've tried the player1 coordinates to trigger them but it just causes the game to glitch, crash or reset, I'll try theloon's method if my current one doesn't succeed, I find out that if you use a counter it works wonderfully, instead of triggering the gosub with the coordinates I trigger it with the counter's value which changes depending the coordinate of the player, I made one for "Y" and one for "X", and whenever the player moves to a specific coordinate depending on if it's the X axis or the Y axis, and depending on the current value of the counter is which screen has to be triggered.

Now I understand how it works, but I have one more question, can pfread be used to check specifically the top row of the playfield, instead of a single pixel at a time, I want to use it for sort of collision detection with the top row in particular but no for stopping the character from going through it, instead I want to use it to trigger a goto another screen, well actually not to another screen but to the previous one, kind of like going back and forth between 'em, do you think that using a counter that adds 1 every time you go to a new screen and substracts one when you return to the previous one, for cycles counting, or RAM saving?

You asked what simple program would I like to see, well I think one with collision, where a character collides with a specific part of the pf and then it jumps to another screen or something like that, of course if its easy if not surprise us RT

Yeah i get that, it basically reads or checks if there is a pixel from the playfield in the given pfread coordinates, or not?

Oh OK, I get it now, to get them to the appropriate size I need to add to lines pero color now instead of one like in the standard right?

So xpos it's the coordibates in the x axis and ypos the ones in the y axis?, or the actual coordinates of a specific pixel from the playfield?

As the title said, can someone explain me how it works, or how to read it, or what values are needed to input in the parenthesis? Thanks.

I have a new question, how does pfread work?, like what is the information you put in the parenthesis, coordinates?

Yeah but I didn't meant that, I meant the size of the sprites

And the funny part is that when the sprites are upside down(literally copied and pasted from the standard kernel game) they show the appropriate size xD

In the DPC+ kernel how can I define the height of a sprite, because my sprites appear squashed, and in the standard kernel they appeared the same way I made them, also do the sprites need now to be generated in the opposite way they used to?, meaning that in the standard kernel they have to be generated upside down, and on the DPC+ are not upside down, first off RT I started making a little test on the DPC+ starting with a test from your site, I think I understood a lot except for those 2 parts; can you help me?, because on your site there wasn't any thing saying about upside down sprites or fixed height sprites... I think.